Update (Sept 20th, 2011): Added daily stand-up meeting step and corrected a few typos.
User stories have a lifecycle from their origin in a Minimum usable feature (MUF/MMF) into development to communicate product expectations between Developers and Product owner, but also for external stakeholders. The User stories also drive the development of the software product to releases of new features. A great source to learn more about User stories is Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Dean Leffingwell). Dean has also published A User Story Primer.
- Release planning meeting: The features are structured in to initial set of user stories. This is done by the Product owner and whole or parts of Development team. The user stories are placed in the product backlog. A project map or project anatomy can be a powerful tool to show dependencies between features (and user stories) as an input to the Release planning meeting.
- Backlog grooming meeting: Those stories not yet presented at a sprint planning meeting are revised, broken down into smaller stories, estimated, and reviewed. The acceptance criteria for the stories are discussed and example scenarios can be defined. The Development team and the Product owner participate in this meeting. This activity provides good input for the product owner’s re-ordering of items in the product backlog.
- Stakeholders’ prioritisation meeting: The Product owner meet with external stakeholders to make the final re-prioritisations of the product backlog before the next sprint. This meeting is typically taking place only few days before start of the next sprint’s planning meeting. The product owner has input from backlog grooming activity and team progress (and impediments) from the latest daily scrum meeting (including scrum of scrum meeting). The stakeholders bring their most recent business needs and updated priorities. Stakeholders can be Product manager, Sales executive, Customer manager, Delivery manager, other Product owners, etc.
- Sprint planning meeting: The Product owner presents an ordered product backlog with user stories. The team revise the acceptance criteria for the user stories. The Development team analyses the product backlog and commit to a subset with the highest prioritised stories, which they will complete in this sprint.
- Start of development of story: This is done as late as possible (but not too late) during the sprint, to minimize number of stories developed in parallel. The Development team may contact the product owner for further clarification on the story. The story’s acceptance tests are written and approved by the Product owner. Some teams have found it useful have one person in the team who is the “driver” of all work tasks associated with the story. Everybody else in the team is available to complete tasks, pairing sessions, discussions, or other help to complete the story. User story driver role is rotated within the team, so for the next user story someone else will be the driver.
- Daily stand-up meeting: The progress of completing the user story is presented for the rest of the team. If the team has adopted the User story driver role practice, this person presents all achievements and planned activities for the story. Impediments or insufficient progress may lead to changed or new tasks for the team members. This includes not only the developers, but also the Product owner and the Scrum master.
- Story development completed: A little bit later in the sprint, the story is now designed, coded and passes all unit tests and the integration test suite. The acceptance tests for the story pass without any problems. At this point the Product owner should be contacted to accept the user story. Remember the definition of done for user stories!
- Sprint review meeting: The whole scope of the development sprint is presented by the Development team for the Product owner and other stakeholders. The acceptance tests for user stories are run to demonstrate the new functionality in the system. The Product owner then approves the all completed stories and the sprint. Remember the definition of done for sprints!
- Release tracking: Each completed user story contributes to the progress of one or several product features. This is monitored by the product owner to check if the release date and contents can be kept.
Please comment on your experience on the life of stories. What link in this chain is the weakest? How can we improve the flow to provide more value for users/customers?