Executable Specifications with Scrum: Refining User Stories by Grooming the Product Backlog
- Managing the Product Backlog
- Collaborating to Groom the Product Backlog
- Ranking User Stories with a Dot Voting Method
- Illustrating User Stories with Storyboards
- Sizing User Stories Using Comparison
- Splitting User Stories Along Business Values
- Tracking User Stories with a Collaboration Board
- Delivering a Coherent Set of User Stories
- Planning Work with User Stories
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
You learned in the previous chapter that iterative discovery of desirements involves expressing user stories with the help of a product backlog. The purpose of this chapter is to learn how to groom the product backlog so that you can plan sprints that will increase the quality of feedback loops.
In this chapter, you will learn the importance of the product owner for the product backlog. This chapter discusses how the team refines user stories by grooming the product backlog. Grooming is the act of ranking, illustrating, sizing, and splitting user stories. You will see how to use collaboration boards to make explicit the grooming process, with a minimum of formality. Finally, it concludes by explaining how to organize effective sprints with story mapping.
Managing the Product Backlog
Nowadays, it is unlikely that new software must address the needs of a single stakeholder. On average, there are easily between 10 and 20 stakeholders. This requires the involvement of several people. If the product backlog is an ordered list, and the stakeholders are responsible for setting the priority, how do you ensure the list actually gets sorted and that every item does not end up being poorly defined? Assigning the product backlog ownership to a group of people is not a viable solution. Scrum recognizes this issue by defining a specific role for this responsibility, the product owner.
The product owner is responsible for ensuring that the product backlog is always in a healthy state. He is the primary interface between the development team and the stakeholders. The product owner is the definitive authority on all that concerns requirements. His main responsibility is to decide the ordering of what will be built and list these decisions into the product backlog.
One of the primary qualities of the product owner is to be the bearer of the vision. He understands the big picture. This knowledge gives that person the authority to prioritize the importance of the desirements expressed by stakeholders. Faced with the unexpected, the product owner knows how to stay the course and is responsive to the stakeholders’ changes.
There is a lot of responsibility (both explicit and implicit) involved in managing the product backlog. Work will not get done without someone actively collaborating with stakeholders to understand customer/market needs and then communicating with the development team to ensure those needs are met. Being the product owner does not mean that he decides alone. The development team actively takes a hand in backlog management.
This new, strategic role is more than just backlog prioritization. It is about facilitating software development over successive sprints and ensuring appropriate customer/market needs are inserted into that process.
Though this role is typically assigned to someone with technical background, someone from marketing or product management is probably just as qualified. If any of these people cannot fulfill the role, someone with a solid understanding of end users, the marketplace, the competition, or future trends can become the product owner. This is not a solitary role—the product owner is most likely part of a larger team—perhaps in product management (if an independent software vendor) or in a client-facing team (if in consulting).