User Story – Smallest Feature Deliverable
Transforming existing business functions or building new product, both need the business and the development team to work together to think through the different user personas, different functionality and features catered to respective personas.
At a very high level, you can carve out business themes aligning with the different business domain.
To sharpen the focus further and separate distinct functions at higher level at a sub domain level, epics are created.
Essentially epics are sizeable work pieces that team can understand more precisely and deliver the features within few weeks/months.
While epics help to collate related features for the same topic, development team needs finest and granular details about each feature. That’s when user story helps.
What is a user story?
User story simply put is a valuable piece of function for the user/consumer of the product/system.
User story generally has format to systematically put together the thoughts about the need.
As a <type of user> I want to <an action to accomplish a goal> so that <the purpose of the goal>.
E.g. As a customer I want to search products so that I can buy it.
As a passenger I want to know the flight status so I can board it on time.
Basically user story sums up the beneficiary/user (Who), the action or interaction (What) user needs to take for achieving the purpose (Why).
It is not mandatory to follow the above format. As long as the business need, its purpose and beneficiary are well covered and are well explained & understood to the development team.
User stories are individual pieces of work that can be completed quickly and deliver a coherent piece of user functionality. User stories are the base of the agile requirement hierarchy. User stories can be written for business requirements, non-functional requirements, and transition requirements.
A user story is fine-grained definition of a need/requirement, containing just adequate information for the development team to come up with a sensible estimate of the effort to implement it.
User stories contain a link to the respective epic and/or theme so that it can be mapped to the bigger purpose. This helps team to align with the mission and understand the purpose beyond the details mentioned in the user story.
Shaping User Stories
User story format as we had seen earlier is a helping hand and not a constraint.
During the transformation you may have a core function and many types of consumers around it. Then you may write the function first, followed by the consumer and then the purpose it serves.
With brand new product idea or brand new offering, it again depends on the origination, it could be a consumer segment or the purpose or the function.
From the product point of view, it would be better to think of the Why first i.e. the purpose.
Why does the product or feature exist? What business value is derived by the respective feature.
This not only helps in defining the value and purpose but it can also help the business/ product owner to decide the priority of the user story in the product backlog. The higher value user story should be accomplished first to derive higher benefits.
Second aspect could be the definition of the user. What customer segment or user role or persona is going to consume the feature. If there are many persona who are going to consume the feature then you may want to focus on the most important persona. This makes sure all the features which are possessing highest business value and are needs of the most user persona are prioritized and shipped first.
Third segment could be detailing of the what i.e. the actions/interactions needed by the user to achieve purpose.
Here’s where the interactions with the actual users are recorded. What are the satisfying criteria from consumers perspective? This helps in validating the understanding and the deliverable too. What data/information would be fed to the process and what outcome would be generated is published to development team and consumers. This drives behavior driven or business value outcome driven development and delivery.
User story slicing
One of the characteristics of a user story is its granularity. This helps many ways. Small information can be digested quickly, when the scope of a function is small then it can be completed swiftly. It avoids success dependent on other factors.
In general below is an INVEST principle suggested in general when working with user stories.
- Independent — The user story should be self-contained, in a way that there is no inherent dependency on another user story. Can the story stand alone by itself?
- Negotiable — User stories are not explicit contracts and should leave space for discussion.
Can the story be changed or removed without impact to everything else?
- Valuable — User story must deliver value to the stakeholders. Does the story have value to the end user?
- Estimable — You must always be able to estimate the size of a user story.
- Small — User story should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
- Testable — User story or its related description must provide the necessary information to make test development possible. Can this story be tested and verified?
User story should be delivered in couple of weeks. If its bigger then it should be broken down further until it becomes granular enough.
The decomposition can happen
- by functional basis e.g. simpler flows, data sets first and complex later by slicing the non functional aspect out e.g. performance can be deferred
- by creating technical stories out of it and separating those.
- by carving out the complex business rules separately
- Remember it the intent is to understand the smallest, most valuable business feature and delivery it quickly (couple of weeks in most cases).
Here are few helpful links to go about it.