A scrum team works from a prioritized list called the product backlog. Product backlog items are often called user stories. In this article we’ll examine the lifecycle of a product backlog item. It starts with conception. You see, when a product owner and a development team love each other very much…
What Is A Product Backlog Item?
A product backlog item (PBI) is a request. The PBI describes a valuable outcome that stakeholders want from the scrum team. When I use the word stakeholder, I’m referring to someone outside the scrum team. Example PBIs include: enhancement requests, bug fixes, and documents. In each case, there is a valuable and verifiable outcome the business wants the team to produce.
Where Do Product Backlog Items Come From?
The PBI is a request for the team to create some value. These requests can come from almost anywhere: customers, sales, marketing, managers, product management, or other teams. Members of this scrum team probably have ideas about what they should build as well. Literally anyone can make a request or suggestion.
How Do We Manage Inbound Requests?
We don’t want every request going directly into the product backlog. That would make a mess. The product owner needs to collect all requests in a holding area. I call this holding area the protobacklog. The product owner evaluates each request and refines it with stakeholders. They will solicit a business value estimate and the initial acceptance criteria. Armed with this information, the product owner decides if this request should be pursued further.
Refining Requests With The Scrum Team
For the requests that make the cut, the product owner presents them to the development team during a product backlog refinement meeting. This meeting is sometimes called storytime or the backlog grooming meeting. Typically, the product owner will invite the stakeholders who care about the request. This allows the development team to interact directly with those stakeholders and thoroughly understand their request. During the meeting, acceptance criteria are negotiated, an estimate is created, and the team indicates if the request is sprint ready. After this initial refinement with the team, the product owner decides whether to add the request to the product backlog, or not.
Welcome To The Product Backlog
Each item that makes it into the product backlog will have the following attributes: description, order, work estimate, and value estimate. The description is often divided into an overview statement and a list of acceptance criteria. The order, sometimes called priority, is simply its location in the product backlog. The product backlog is a strictly ordered list; no two items are of equal priority. The work estimate is created by the development team and is frequently expressed in story points. The business value estimate is created by the stakeholders and is often expressed in value points. If that last bit intrigues you, you might be interested in learning more about business value estimation in our Certified Scrum Product Owner and Advanced Certified Scrum Product Owner workshops.
Where Do Rejected Items Go?
It can be useful to keep requests that didn’t make it into the product backlog. We don’t want them cluttering up the protobacklog, so we put them in the icebox. The icebox is where requests go to die, or at to least wait in suspended animation. The icebox is an unmanaged list that doesn’t get any additional attention or effort. Every once in a while, something happens that makes an old request more interesting and the product owner can thaw it out and move it back to the protobacklog.
Further Reading And Listening
- This article was recoded as Episode Seven of the Agile Software Development Podcast.
- Learn about story splitting at SmallerStories.com
How do requests get into your team’s product backlog? Leave us a comment and let us know.
Cheers,