Spoiler alert: It's not magic.
The Product Backlog Defined
The product backlog is how we capture what the user needs from the product. It consists of a prioritized stack of features captured in the form of user stories (what the user needs to do) with acceptance criteria (the things you need to demonstrate can be done with the product). It's easier to see this with an example:
As a registrant, I want to sign up for the event via a web site, so that I can attend your event
Acceptance Criteria
- I should be able to sign up without providing a phone number
- I should not be able to sign up without providing a first name and last name
- I should not be able to sign up without providing an email address
This is a very simple example and requires more detail before it would be considered ready for development. In practice, it might even be chopped up into smaller stories. But it conveys the general idea, and a story can be added to the Product Backlog even if it is incomplete or requires refinement.
The Product Backlog is basically a single stack of User Stories. The closer to the top a story gets:
- The greater its value to the customer
- The higher its priority
- The more defined it is
The Product Owner Owns the Product Backlog
The Product Owner has the ultimate ownership of the Product Backlog, being the ultimate arbiter of the ranking of stories on the stack. User Stories in the Product Backlog can be changed by the Product Owner at any time.
If anyone wants to suggest changes in priorities or to add/subtract features, they talk to the Product Owner. If someone bugs the development team about features or their priorities, they should be intercepted (ideally, by the Scrum Master) and routed to the Product Owner.
Backlog Grooming And Refinement
The Product Owner should feel free to manage the Product Backlog whenever he likes. I highly recommend trying to constrain this to the Backlog Grooming and Refinement meeting. This is a two-hour meeting in which the Product Owner, Scrum Master, and Development Team get together to:
- Add items to the backlog
- Update priorities of items
- Create development estimates for items higher on the stack
In your first sprint or two, you may still be refining the vision and essential features, so you may need to focus on completely fleshing out just enough items to insure you are creating high value product in the imminent sprint. Once you get past those first few sprints, you should have a pretty comfortable lead on filling the stack up so you always have plenty for the team to develop.
What About Random Thoughts For Features?
Sometimes you have a random thought or here a stray comment that might result in a valuable feature. You have the option of slapping it on the bottom of the Product Backlog. You can always take it off if you change your mind, and until it is refined and moved to the top of the stack, it's not going into development.
Because of this, I tend to err on the side of inserting what I call "placeholder" stories on the bottom.
In a similar vein, I am a fan of creating stories in the backlog as we identify them, which is perfectly legitimate in Agile/Scrum. Have a rough idea? Slap it on the stack, below the better-defined ideas; I like to slap "WIP" on the front of the name for clarity.
In a similar vein, I am a fan of creating stories in the backlog as we identify them, which is perfectly legitimate in Agile/Scrum. Have a rough idea? Slap it on the stack, below the better-defined ideas; I like to slap "WIP" on the front of the name for clarity.
The Product Backlog & Sprints
When the team meets for Sprint Planning, the Product Owner will again have an opportunity to reprioritize the backlog before items are selected for the sprint. This insures that the most valuable features are going into development.
At the end of a sprint, during the Sprint Review, if items are deemed incomplete, they return to the Product Backlog.
Facilitating Agility, Mitigating Obstacles, and Maximizing Value
This ongoing capacity for reprioritizing the backlog allows the Product Owner to be remarkably responsive to changing needs. The first obvious impact is that you can rapidly reprioritize what is going into development. In other words, you are agile.
One way you can apply this agility is to mitigate hurdles. A user story goes into a sprint, but some task essential to it blows up because of a missing resource, technology, etc. No worries, leave it on the backlog while that concern is addressed and keep moving forward. This is part of the reason many say there is no critical path in Agile/Scrum.
The more common benefit is that this agility dramatically increases the likelihood that items of value to the customer are being created and that the resulting product most accurately reflects the currents needs of the customer and the intended market.
Managed properly, a Product Backlog is a powerful engine that powers the "Agile" in Agile/Scrum.
One way you can apply this agility is to mitigate hurdles. A user story goes into a sprint, but some task essential to it blows up because of a missing resource, technology, etc. No worries, leave it on the backlog while that concern is addressed and keep moving forward. This is part of the reason many say there is no critical path in Agile/Scrum.
The more common benefit is that this agility dramatically increases the likelihood that items of value to the customer are being created and that the resulting product most accurately reflects the currents needs of the customer and the intended market.
Managed properly, a Product Backlog is a powerful engine that powers the "Agile" in Agile/Scrum.
No comments:
Post a Comment