The size and shape of an ideal Product Backlog

How long should a Product Backlog be? How should it be organized? Is there a universal rule of thumb or is it product-specific?

The lifecycle of a requirement

To understand how the backlog should be organized, we need to look at what happens with a requirement as it changes from an initial concept to a working implementation.

This is a multi-step process:

  • First, there is a rough idea: we want to sell flight tickets.
  • Next, we decompose this idea into a bunch of rough features: the customer must be able to search for a flight, we must gather personal data to book a flight, we need to handle various forms of payments, we must be able to send the customer a ticket and so on.
  • Finally, we decompose each feature into fine-grained user stories: we need a form to gather personal data, the form should have validation, we should display informative error messages if data is invalid, after submitting valid data the customer should be asked about preferred form of payment etc.

Of course, there may be more steps, especially for a new product. However, we can roughly distinguish 3 general types of product backlog items:

  • projects
  • project components
  • implementation details

3 levels of decision making

The 3 types of items (projects, project components and implementation details) require decissions at different levels and by different people:

  • At the project level, a PO supported by key stakeholders and management decides which projects should get “the green light” and in what order: Is selling flight tickets worth investing at all? Should it be done before or after selling hotel reservations?
  • At the project component level, a PO supported by stakeholders, domain experts and a dev team decides which features are critical for a project and will generate the most value: Do we need all forms of payment to sell flight tickets? Can we support only one in the first version? If so, which one has a better balance between the implementation cost, operational cost and usability?
  • At the implementation details level, a dev team supported by a PO, domain experts and stakeholders decide how to build a feature most effectively: Can we gather customer personal data without validation? Can we validate only if the fields are non-empty? Do we have to display detailed error messages or can we just mark the invalid field with red color?

3 levels of details

Making decisions at different levels requires a different level of details in items descriptions:

  • Decisions at the project level require strategic information: How big is the flight ticket market? How competitive it is? What are estimated profit margins? What are the opportunity and delay costs?
  • Decisions at the project component level require operational information: How many customers prefer credit card payments over bank transfers? What are estimated operational costs of handling bank transfers?
  • Implementation level decisions require low level information: Is every field of customer personal data required for flight check-in, or are there any optional fields we don’t have to validate? Do we need backend validation for security reasons, or is our goal only to improve user experience so frontend-only validation is enough?

Decomposing too much is wasteful and hinders decision making

Decomposing a rough idea into fine-grained user stories is a lot of work. People making decisions at a high level don’t need these details. What’s more, the more coarse and the further in future backlog items are, the higher the chance they will be reprioritized, modified or even completely eliminated. And even if they won’t, it’s not possible or cost effective to write all the smallest details down, so the more time passes between the decomposition and the implementation, the more of these details will be forgotten. Therefore, premature decomposition of backlog items is a wasted work: not only the results of this work won’t be used by anyone, but they will also deteriorate and lose their value over time.

Decomposing backlog items too much is not only wasteful, but also renders high-level decision making difficult. It’s easy for key stakeholders to discuss if it’s a better strategy to sell flight tickets or hotel reservations. But it’s almost impossible to discuss what will have bigger strategic impact: validating optional fields of the flight booking form or adding detailed error messages on a hotel reservation payment screen, especially if the backlog contains hundreds of such items.

Decomposing not enough or too late hinders development and causes rework

On the other hand, developers work most effectively with fine-grained user stories and they need to know all the low-level details. If the stories aren’t decomposed enough, developers must clarify all the details during implementation, what creates random delays, disastrous to the flow of the sprint. It has a negative impact on development speed, predictability and commitment, and in extreme cases can even block development completely.

Implementation based on coarse-grained requirements is also wasteful. When backlog items are decomposed in advance, there is time to clarify or prototype things, wait a couple of days for an answer etc. But when requirements are decomposed during development there is no time for this, so developers often just guess, which results in a lot of fixes and rework later.

Decomposing just right and in time: a pyramid shaped backlog

An ideal product backlog must balance all 3 levels of items. The top, highest priority items, ready for development in the upcoming sprint, must be fully decomposed so the developers can work smoothly. Items next in the line must be more coarse-grained, so the PO can prioritize different parts of projects currently in progress or just about to be started. Projects further in future should not be decomposed, or decomposed only minimally, to allow easy strategic planning.
To avoid waste, at each level of decomposition there should be no more items than necessary.

This is often pictured as a pyramid, with smallest items at the top, a bit larger in the middle and the biggest at the bottom. In reality this shape can be slightly distorted, as priorities change and some of the already decomposed items may drop down below the more coarse-grained ones (or the coarse grained may get promoted higher in the backlog). However, this doesn’t happen in masses and doesn’t cause the backlog to become a random mess. It may happen that a few implementation level items drop below the top project component level item or two, or that a component level item drops below a project level item. However, it rarely happens for more than a couple of items, and it almost never happens that an implementation level item drops below project level item. If the priority of a user story drops so much, it should rather be removed from the backlog completely.

How many items at each level?

Implementation level details are needed only for items that will be developed during the upcoming sprint. In theory, it means that one sprint of items is enough. In practice, though, we need some room for last minute re-prioritization, a small buffer in case the development team completes more stories than initially planned etc. Therefore, we need at least 1,5 sprint of items, but no more than 2 sprints to avoid waste. Considering that a typical team takes about 4-8 stories per sprint, this translates to about 6-16 implementation level items in the backlog.

Project component level details are needed for the project currently in progress and possibly for the next project (especially near the end of the developemnt of the current one). Components are bigger that fine-grained user stories so a component is typically at least half a sprint to a sprint in size. Again, having more components than necessary is waste, so we should have no more than 2 months of components, which for two-week sprints translates to about 8-10 components.

At the project level, a reasonable planning time span is 3-6 months, in extreme cases up to a year, but I think a year is usually too much. Projects are bigger than components, at least 1-2 sprints in size, so 3-6 months of projects means about 3-12 items for two-week sprints.

Summing all the 3 levels up, even taking the higher values and adding some buffer for already decomposed items temporarily dropping in priority etc., we get a backlog no longer than about 50 items. Such a backlog is manageable and easy to work with at all levels of a pyramid.

How big is your backlog? Do you have any rules of thumb how to organize it? Please share below in the comments!


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s