What does the Scrum Guide say?
“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.”
How we do?
Once the PO has defined a product backlog item; clearly expressed what needs to be built and the item has business value, it becomes ready for refinement. If one of the qualifiers is missing it is waste of time and effort.
How often?
Refinement should be a continuous activity if product backlog items are not refined to a sufficient level (everyone in the scrum team should be able to understand what it is) sprint planning becomes cumbersome.
Who participates?
It highly depends on the nature of the backlog item. It is hard to find the balance. At one hand if anyone of the team can participate, without having proper domain or technical knowledge, things can go wrong easily by building an architecturally poor (unemployable, technical debt heavy etc.) solution. On the other hand if not everyone is involved it could cause low moral and lack of commitment. Those involved in creating the plan will be committed to seeing it through execution.
That’s why two level refinement has been introduced:
- One at high level by agreeing on the story with the PO and defining an architecture of a system delivered in context of a specific solution of the backlog item . Executed by the PO and the senior devs / architects.
- Another one at implementation level by defining implementation details and the sub tasks. Executed by smaller groups formed from the dev team.
We will carry on with the Planning in the upcoming post.