The product backlog is the bucket from which you pull work. It’s a list of all items that potentially make it into the product. It’s the single source of requirements. That sounds easy enough. Perhaps it is, too. Yet sometimes it isn’t obvious what to put in the backlog, and how to select what items to work on next.
One challenge is to manage non-features such as technical items and bugs (in the rare case you have any, of course). People have different strategies to deal with the not-so-obvious stuff.
It can also be overwhelming to add “everything that goes into the product”. However, don’t interpret that the wrong way: the backlog is dynamic, and evolves alongside the product. As more is learned and business requirements change, so does the backlog.
The Product Backlog Should be DEEP
Characteristics of a good product backlog is summarized by the DEEP acronym.
- Detailed enough. Don’t specify more than necessary. Future items can be described in less detail.
- Estimated. Items in the backlog should be estimated, or at least estimable.
- Emergent. The backlog is dynamic. It changes to reflect new requirements and knowledge gained as the product is developed.
- Prioritized or ordered. The backlog should be ordered so that items that will be worked on next are located first.
The product backlog is made up of backlog items. Backlog items can be pretty much anything describing stuff that comprise the product. For example a requirement specification. However, most people use user stories.
A user story is a short description of a value-adding feature. It is often written in the form below. The idea is to put emphasis on who (as a…) the feature is for, and the reasons (so that…) for it.
Writing stories in this form can be difficult, especially when you’re not used to it. For example, it is not always obvious who the target user is.
Chances are also that you’re implementing something for another sub-component or to meet an external requirement. Even so, I think it’s feasible to write meaningful stories in this way. For example: “The database subsystem wants time to be specified in UTC so that data is consistent independent of local time.”
Including why the feature is needed (the business value) enables developers to make informed choices and give suggestions on alternatives.
INVEST in the Stories
To remember how to write good user stories, you may want to remember the INVEST acronym.
- Independent. The story should add value to the product independent of other stories.
- Negotiable. The story should be negotiable. It is not an absolute requirement.
- Valuable. The story should by itself add value to the product.
- Estimable. It should be possible to give an estimate for the story.
- Sized right. The story should be sized right. For example small enough to be implemented in one iteration.
- Testable. It should be possible to verify that the story has been implemented as intended.
Don’t overdo it. Keep in mind the agile principle of simplicity: the art of maximizing the amount of work not done. In my experience you can become crippled when trying to add everything at once. Remember that the backlog is dynamic.
For more on the product backlog, I recommend this article over at Agile Bench.
Next time I’ll write about estimating the items in the product backlog.