Product Backlog Refinement
Product Backlog Refinement is a Scrum activity that is performed on the Product Backlog. The scrum guide defines Product Backlog Refinement as the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
In A Nutshell
The team takes responsibility for ensuring that there are sufficient product backlog items ready for work to sustain the workload of the team for a sprint or so. Product Backlog Refinement consists of taking existing backlog items and reviewing their deficiencies. Before refinement, items will lack sufficient detail to be worked by the team. Product Backlog Refinement identifies what is missing so the team can discover and record the missing information. It will become apparent that many items are too large to be worked effectively. The team decomposes backlog items until they are right-sized for work in a sprint.
The completion of a backlog item is the delivery of value to the customer. When broken down, each smaller backlog item must still represent a unit of value to the customer. Typically, then, each item must still embrace all layers of the solution architecture.
We have observed that many teams, especially teams who lack experience, pay insufficient (or no) attention to Product Backlog Refinement. In consequence there are few or no items ready for work at the start of Sprint Planning. Sprint Planning becomes the point where refinement is attempted. The result is substantially extended and ineffective Sprint Planning session. The quality of backlog items remains deficient and significant work is left incomplete at the end of the sprint. Items that are complete may receive negative feedback during the Sprint Review because their specification in backlog items was inadequate.
Related Practices
The Product Backlog is the vehicle by which needs are turned into requirements and requirements are turned into operational features in our product. It is a prioritised list of the work that the team currently intends to deliver in the next period of time. The less imminent a feature is, the less well it will be defined.
Related Articles
Relative estimation is a simple concept, but one that causes all sorts of problems for new teams and for experienced agile practitioners. This article examines some of the reasons behind the confusion and suggests a new, clearer way of thinking about the process of relative estimation. This new pattern makes a very clear break from more traditional estimating techniques.