The Product Backlog groups the User Stories of the product. It is obvious that it is not desirable that all User Stories are detailed from the beginning of the project. This refining must be done over time. But how fast?
An insufficiently detailed backlog can slow down the team in case it needs to take User Stories from the Backlog. Conversely, a backlog too detailed, too clear, prevents the product from adapting during development and kills the creativity. The answer to this question is provided by the 20/30/50 Rule:
- 20% of the Backlog User Stories must be fine-tuned enough to be actionable as soon as the Development Team needs it; in other words, these User Stories are ready to be developed;
- 30% of the Backlog User Stories must be in a state that allows to start discussions between the Development Team and the stakeholders; in other words, these User Stories are pretty well formed, not detailed enough and can look like Epic User Stories;
- 50% of the Backlog User Stories are in a vague state, are more like themes, ideas; it is up to the Product Owner to determine which of these User Stories should be considered and which ones should be dropped; in other words, they are "big" Epic User Stories.
This rule was introduced by Bob Galen in his book Scrum Product Ownership.
This rule can be applied at any time: during Refinement Backlogs of course, or Sprints Planning; but also at any time, as soon as the team needs to estimate the size of a User Story.