We earlier talked about the Role of User Stories in Agile and How to create a good one. Did you know that tasks within each user story have a whole lifecycle which can be highly significant for your product owner (customer) and your team to see the status as well as quality of the development?
This must be established, by now, that user stories play a vital role in ensuring customer’s active involvement throughout the development. In the current post, we would bring out what all should a lifecycle of user stories entails and why focusing on it is important for effectively implementing Agile.
In Agile, every Sprint backlog includes a list of user stories as well as the flaws that your team has committed during a particular sprint. The lifecycle of a user story proves very significant in checking the status of the development, quality, and velocity.
Using task boards, the product owner (or customer) can check the velocity and also measure whether the development deadlines are being fulfilled.
Consider the following example to understand better how the lifecycle of user stories help in a given scenario.
Building product ‘A’ using the traditional waterfall process, the product owner does not know the probability of the product’s success unless the product is close to its completion. After spending several months over the development, the Team and Product Owner face disappointment learning that the product development did not match the original business needs. Here, reverting to the planning stage is a highly taxing situation for both parties.
However, while building the same product ‘A’ using Agile, the Product Owner could leverage the daily scrum board to simultaneously monitor the probability of achieving the product’s success. Here, the lifecyle of user stories enhances the monitoring by allowing visibility of Team’s activities to the product owner.
Let’s take you through a quick tour of what all a task’s lifecycle in user stories should include.
To Do: Ready list by the Product owner which is also Approved By Client
This is the initial stage of a task in a user story where the requirements are clearly stated by the customer or client and well received by the Product owner. At this stage, the requirements are framed in the simplest form, drafted by the product owner and then approved by the client, which forms the Sprint Backlog for the upcoming sprint. The stories are ready to be picked by the Team.
In Progress: Ongoing Team Activity
This stage follows the to-do or “not started” stage and the actual development or design work begins here. This stage of a task’s user story lifecycle allows the team to actually monitor the per day speed or velocity of the sprint.
Quality Control: Under Testing
Here the User story goes for a quality check before being submitted for an acceptance testing or being moved on to the state of “completion”. In case of any defects reported by the quality assurance team, the changes are referred back to the team and the User story goes back to ‘To-do’ stage.
UAT: Product Owner, Validates Business Acceptance Criteria
This is the most crucial stage of the task’s lifecycle in a user story. The developments made in the previous stages are now referred to the product owner for User Acceptance Testing (UAT). The user or the product owner validates the recorded business acceptance criteria at this stage and approves or disapproves the story.
Not Approved: Back From QC And UAT
It, however, emerges in two forms. the User Story can be referred back to “In progress” stage either after the changes suggested by the QC team or after the UAT. The User story moves back to ‘In progress’ state and the development or design team again works on the requirements to rectify the defects (pointed out either during user acceptance testing or quality check).
Done: All Acceptance Criteria Are Met
This the most vital and desired state before the sprint review. A user story moves from “In Progress” to “Done” when the team successfully completes all the recorded requirements. Here, all the acceptance criteria are considered to have been met by the project team.
Points to Ponder For Ensuring a Smooth Transition Across Stages
- The product owner will accept the user story only when the team is able to successfully demonstrate completion of acceptance criteria.
- It is an uncommon that story gets rejected or totally cancelled but this situation arises when the product owner has an afterthought that the story was not required. This may trigger due to changing market demands or other reasons.
- The sprint is considered to be ‘DONE’ when the sprint backlog is completed with each story reaching the ‘DONE’ state.
Unlike in a Waterfall-oriented process, where the Quality Testing and User acceptance testing needs to wait until the end of the project for quality checks, in Agile, the task’s lifecycle facilitates faster visibility. The lifecycle also gives better visibility to the Scrum master and the product owner on the overall productivity of the team.