Zen of Scrum: Product Backlog and The Story Behind

By Unknown


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.

Backlog Items

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.
Independent relates to value, not implementation. The story should add value independent of other stories. However, one backlog item may very well require some other bit of functionality before it can be implemented.

Final Thoughts

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.

1 comment:

  1. James Lackey8/30/16, 9:11 AM

    Nice post..Well,I’m absolutely delighted I establish it and I’ll be bookmarking it and read-through back over and over again! OOH ERP permits publicists to appreciate expanded engagement with groups of onlookers in ways different mediums basically can't coordinate. Outdoor advertising can be put where the message truly checks: it's the main medium where you can catch the gathering of people in setting and near the purpose of procurement.