Backlog Structure | 20-30-50 rule

What is the right level of detail for product backlog? 20/30/50 rule by Bob Gales gives you guideline on how to structure product backlog.

What is the level of detail in your product backlog?

If your backlog items are not well defined, then the team can pick up stories that aren’t immediately actionable and it can slow down the overall progress. If the Product backlog is over-defined then it becomes rigid and might fail to evolve as the product takes shape. A super clear backlog (too detailed) prevents the product from adapting during development and kills the creativity.

20/30/50 Product Refimenement Rule by Bob Gales

Tweak percentages accroding to your product, find what works the best for your product.
20/30/50 will provide you guideline but as with any other agile principlesis – it is not dogmatic.

- 20% -
Stories are precisely defined and ready

Stories are ready to be picked up at any time, immediately actionable - team can start working on it.

  • Specify objective – what we want to achieve?
  • Provide context – why we do it? how it helps? who will use it?
  • Clear specification - definition of done - what is the end state of story?
  • Define success criteria - metrics

- 30% -
Stories are in good enough state

It’s not recommended to pick-up stories from this bucket as there might be a lot of open questions, uncertainty in specification or missing context. On the other hand, it might be good enough for initial discussions with team, stakeholders, customers, etc. – in order to decide whether it’s worth of doing it.

  • Specify business objective - what we want to achieve?
  • Provide business justification - why we do it?

- 50% -
Not ready for team or discussion

Stories are not ready to start working on them and even not ready to have a discussion about them. Product owner should watch over these stories periodically and evaluate if they still make sense for the future product direction. It exists mainly to shape your product and gives a vague ideas of things the team might consider to build in the future.

By Lubos Schramek on October 27, 2020 in the Agile notes

Related posts to Agile notes

Agile is not an excuse for a lack of Roadmap

By Lubos Schramek on October 01, 2020 in the Agile notes

Agile teams must absolutely know where they are going... and the goals they want to achieve must be clear.

Agile is not excuse for POOR quality

By Lubos Schramek on September 30, 2020 in the Agile notes

the Triple Constraint; success of your product is impacted by cost (budget), time (deadlines) and scope (features).
As product manager you can trade between these three constraints.

Agile ≠ Dogma

By Lubos Schramek on September 29, 2020 in the Agile notes

You are not agile if you dogmatically follow process (even specific agile framework) – instead of adapting your activities in order to achieve your goals

Product backlog is not documentation

By Lubos Schramek on September 23, 2020 in the Agile notes

Keep product documentation somewhere else - use Google Docs, Notion, Miro, GIT, Sphinx or any other tool. Don’t use tasks as documentation.