Creating a Great Product Backlog
Your team creates a product backlog, which usually contains user stories, to represent what its customers need and value. Over the course of the project, your team will add detailed information to the user stories, break them down into smaller stories, prioritize and estimate them, and finally, implement them and deliver the results to your customers. By writing great user stories and continuously updating the product backlog, your team can more effectively deliver value to your customers.
Bill Wake summarizes what makes a good user story by using the INVEST acronym (independent, negotiable, valuable, estimable, small, and testable). For more information, see the following Web site: XPlorations. Mike Cohn discusses how to write user stories in one of his books, and you can download the relevant chapter from the following Web site: User Stories Applied for Agile Software Development.
When your team creates a user story, make sure that it represents customer value by answering the following questions:
Who the user is
What the user needs to do
Why the user needs to do that
In most cases, your team can accomplish this by creating an effective title. Mike Cohn suggests the form "As a <user>, I need to <action> in order to <reason>". You can see this approach in the example "As a customer support representative, I need to access customer information so that I can more quickly respond to customer questions." In many cases, the reason is obvious. For example, "As a vegetarian, I can filter my view to see only vegetarian meals."
The user stories should also be defined in a way that allows them to be implemented in any order. However, it is not always practical to make the user stories completely independent. Bill Wake and Mike Cohn both describe techniques that your team can use when making user stories independent is a challenge.
User stories that are valuable and independent, as previously described, make up the product backlog. They are estimated and prioritized, and then your team starts to work on the highest ranked user stories. Before your team implements a user story, it must have the characteristics in the following list. Your product owner will work to make sure that the user stories that are ranked highest meet these criteria before bringing them to a sprint planning meeting.
Small enough to be implemented in the sprint
User stories that are about to be implemented must be small enough to be finished in the sprint. Your product owner will work with your team to break down user stories that are too large. For example, the user story "As a customer support representative, I need access to customer information so that I can more quickly respond to customer questions" may be too large to finish in a sprint. It could be broken down into stories such as "As a customer support representative, I need to access the customer’s name and the recent call summary by using the customer's phone number" and "As a customer support representative, I need to access the customers’ full call history so that I can research the current problem in more detail."
Just detailed enough to describe and estimate the work that is required to implement the story
Before they are included in a sprint, user stories are estimated in story points. These are intentionally rough estimates that are primarily used to manage the backlog and to help prepare for the sprint. When a sprint starts, your team will break the user story down into the tasks that are required to implement it. Your team will work with your product owner in the product backlog grooming meeting to determine which stories need more information before they can be broken down into tasks to estimate the hours of work. Your product owner can gather these details and record them in the user story’s description.
Be careful not to add more details to the user story than necessary. The user story should be the basis for a conversation and negotiation with your product owner and customers that continues until the user story has been finished and accepted. Too much detail can impair the negotiation by creating an implication of precision that is not accurate.
Acceptance criteria defined
At the end of a sprint, your customers or your product owner will either accept the user story as finished or reject it. Before the sprint starts, the criteria for customer acceptance should be described as clearly as possible. Of course, a user story may not be accepted for reasons that were not anticipated. However, the conversations that your team has with customers to help define the acceptance criteria will help ensure that your team understands your customers’ expectations. The acceptance criteria can be used as the basis for acceptance tests so that you can more effectively evaluate whether you are finished with a user story.
Epics and Themes
It is frequently said that user stories should be small. That is true for the user stories that are about to be implemented. However, the stories that are ranked lower can be larger. In fact, keeping them large is a good way to keep your product backlog from becoming too large to manage. User stories can be broken down into smaller user stories as they approach the top of the prioritized product backlog. It is helpful to think of large user stories as epics and themes.
Epics are very large user stories that represent a significant amount of work. When you break an epic down, you may create many themes and other, smaller user stories.
Themes are user stories that are fairly large, generally larger than you would implement in a sprint. Before your team implements a theme, it must be broken down into smaller user stories.
When you prioritize the product backlog, break down epics and themes that are near the top, and prioritize the new, smaller user stories. When you are finished, the highest priority user stories should be small enough to implement. Lower in the prioritized backlog, most of the user stories are generally larger.
Spikes
Your team will sometimes need to do work that is not a direct implementation of a user story. This work is called a spike. Three common types of spikes are research, bug debt, and process or engineering improvements. To create a spike in Team Foundation, create a user story work item, set the type to Spike, and then prioritize it in the product backlog together with the other user stories.
Research
Research occurs when there are open questions about a user story that must be answered before the user story can be fully broken down into tasks and estimated. For example, the team comes across the story "As a frequent flyer, I can book award travel" during a sprint planning meeting. After discussing it, they have more questions than answers. The team creates a user story to represent the spike. "As a team member, I can understand what ‘book award travel’ means so that I can write stories to include in future sprints." The team determines how many hours it is willing to dedicate to that research and writes that number as the timebox for the spike. None of the stories that are written during the spike can be done during that iteration. The work must be scheduled for a future iteration by using the product backlog.
Bug Debt
The best time to fix a bug is when you find it. If you cannot fix it on the same day that you found it, you should create a bug work item to make sure that you do not lose track of it. Be careful to avoid accumulating bugs. If your team does accumulate bugs, create a user story, and link the bugs to the spike so that it can be estimated and prioritized together with other user stories and spikes.
Process or Engineering Improvements
Your team will undertake process or engineering improvements that help drive it toward success. These improvements are often identified during the sprint retrospective and daily scrum meetings. For example, your team might need to improve code coverage by the unit tests or reduce the build time on the continuous integration server.