User Story Life Cycle
In the Agile system, functionalities are developed incrementally, and a User Story is an increment that the team has agreed to deliver to the customer or user. Every User Story must add value to the product. As we know, the User Stories are usually written by the Product Owner or Product Manager and then forwarded for approval. However, anyone who has a good understanding of customer problems and requirements can write User Stories. But whosoever writes the User Story must clearly describe who is the end user or customer, what needs to be done, why it has to be done, and what value would be added. A well-written User Story affects its lifecycle at every stage.
User Story Lifecycle
When we talk of the life cycle of a User Story, it means the different stages it passes through before being considered Done and having delivered the desired value. The first stage of the User Story lifecycle in Agile is when the customer requirements are defined, and the lifecycle ends when the User Story is delivered to the user. It is an essential tool for keeping track of how the product is developing and its quality. The User Story life cycle is also essential for monitoring the velocity at which the product progresses. Another significant contribution of the User Story life cycle is the increased transparency in the team's work as its activities are more visible. Before putting the User Story into the Sprint, it goes through 3 C's, i.e., Cards, Conversation, and Confirmation. This means writing the story on the cards, discussing the story with the team, and then confirming the Acceptance Criteria for the User Story.
Once this has been done, the User Story is ready to be taken up for work. Now its lifecycle starts, and it passes through various stages before being finally delivered to the customer. We will now discuss these different stages of the life cycle of a User Story.
Story writing workshop
The first step in the User Story life cycle is holding a User Story writing workshop. A product vision has already been created. The User Story writing workshop aims to express this vision of product features in the form of User Stories. But to do this, you must make sure that you have prioritized Epics. You will create the User Stories out of them only. This way, the backlog is populated and is used throughout the project. When the workshop is completed, the team has a good number of User Stories, each containing its information. Preferably, this workshop should be a collaborative effort. The story writing workshop is usually a brainstorming session, and the team for this session usually comprises the customer, Product Manager, Developers, and Testers. The team also decides on the iteration length and the team velocity during this workshop.
Prioritizing the User Stories
Prioritizing the User Stories is the next stage of the User Story life cycle. The objective here is to place different User Stories in order of the urgency of completing them. So, after assembling various User Stories on the cards, the Product Owner gets down to set their priority. This is important because the Agile team cannot work on all the User Stories on the board. So, it is only natural that they prioritize simultaneously. Here, the urgency of each story is gauged against all the other stories in the backlog. The Developer's views, ideas, and feedback are also considered when deciding the priority. One commonly used method of deciding priority is MoSCoW (Must have, Should have, Could have, and Will not have features). This dictates the urgency on which the User Stories should be taken up and their priorities.
Must-have features are the ones that have to be there in the product, meaning they are essential and are the basis of the product. Should-have features should be included in the product to add value to it, and the priority is decided once the Must-have features are completed. The Could-have features are the ones that, if added to the product, can further add some value to it. However, these features can be avoided with a budget or time constraint. And lastly, they will not have features that provide less or no value to the product and so can be ignored. These are the features that the customer would not bother much about. Once the priority is set, the team has clarity over where its focus should be, thus giving it the right direction. In the end, one should provide logical reasoning for the set priority, which means it should be clear to everyone why a particular story has been placed ahead of other stories in priority.
Backlog Refinement:
The backlog refinement aims to ensure the stories are ready for implementation. The Developers get together to bring out the technical obstacles that may surface or the dependencies on other teams. Then a cost-benefit analysis is also done to explain the cost involved and the likely benefit it would give. So, several high-priority stories are taken up that the team wants to implement at the earliest. The team holds extensive discussions on the technical details. This is another brainstorming session to exchange ideas. The result expected from the backlog refinement sessions is to achieve a more refined User Story, and when it looks beneficial, it may be broken further. The idea is that the story coming in should meet the Acceptance Criteria laid down earlier. It should also bring clarity on how to move forward. It should also include a Definition of Done so that the results can be validated later on its basis. Ultimately it boils down to deciding if the story would deliver enough value to the customer to be taken up immediately.
Sprint Planning session
Sprint Planning is something everyone familiar with Scrum knows about; the team sits together and decides on how the work will be done and in what order during the forthcoming duration of work. It is highly likely that before the team sits down to plan a Sprint, it would have presented its solutions and the backlog to the customer. It is an opportunity to see if there are any more errors or ambiguities so that the backlog needs to be further refined. It is a chance for the Developers to show solutions to all the Stakeholders and the team involved in the Sprint Planning session. It should ensure that the User Stories in the Sprint Planning session are well-refined and have been discussed thoroughly beforehand. Sprint Planning should not be a drain on energy; instead, it should boost efficiency. The previous steps are reviewed to ensure that the information gathered remains pertinent. The Sprint Planning session should end with the team agreeing on the backlog for the first Sprint. The team should be ready with the stories, their Acceptance Criteria, sketches, and wireframes. Thus, the stories are ready for implementation.
Implementation
Now that the team is ready with the stories, it is time to implement them. As the team executes the Sprint, it learns if it has prepared well. This will be reflected in any new tasks coming up or some tasks taking more time than estimated. The team must find the best possible solution to deal with such situations. It will also get valuable experience and input for planning the next Sprint. Once the Sprint is completed and you have a working product ready, a demo of the product can be given to the Stakeholders. User Stories describe what has been done and what remains as the demo occurs. At this time, Stakeholders also provide their feedback about the product and suggest changes required, if any. These suggestions can also be turned into User Stories and implemented in the subsequent Sprints.
Testing
When a User Story is finished, it must be tested for its efficiency and functioning. The team might have done its best in implementing the User Story, but it has to be ensured that it works and provides the right solution expected by the customer. So, the testing team tests the User Story for its working and efficiency. The tests are unit, functional, and acceptance tests to see if the completed story fulfills the Acceptance Criteria. Once the User Story meets the Definition of Done, it is ready for release.
This is where the User Story life cycle ends. It has cleared the Acceptance Criteria test. Ultimately, what counts is what you complete in the Sprint. If a User Story can not be completed in a Sprint, it is sent back to the Product Backlog and scheduled in the subsequent Sprints. These are the various stages of the User Story life cycle in Agile.
References
- https://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/2277/Describe-the-life-cycle-of-a-User-Story.aspx
- https://agilephilosophy.com/2015/04/17/the-life-of-a-user-story/
- https://www.netsolutions.com/insights/user-stories-in-agile/
- https://manifesto.co.uk/life-user-story/
