Refinement in Scrum

"Refining breaks crude oil down into its various components, which are then selectively reconfigured into new products." - CEEF

Crude oil is refined into various, better and more defined products. Each end product is of better quality than the crude oil was. Refinement in Scrum is no different. Stories are scrutinized, broken down and up, sliced, inspected and adapted until there is a better quality story. But how does refinement work in Scrum and who should be there?

"Product Backlog refinement is 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.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs." - 2020 Scrum guide

It is not clear, by the 2020 Scrum guide, who is responsible and it is not clear who will attend. Since the product owner is responsible for the backlog he/she makes a good candidate to be responsible for the quality of its contents. The developers must use the product backlog items to work with; unclear stories might slow them down. For their own sake, developers are pretty good candidates as well. If we look at who will attend a refinement the best answer would be: those that are needed to make the story understandable. Most of the time this will be the developers or a subset and most of the time with the product owner. Sometimes we might need more developers and sometimes we should even invite the reporter or stakeholder to clarify.

According to the Scrum guide, the refinement (which is mentioned only once) is an ongoing process. And in the old guide (2017) about 10% of the time is reserved for refinement. This is up to four hours a week. This sounds like a lot of time, however in waterfall environments this time has already been spent in the planning before coding even started. Refinement is about understanding what needs to be done and that needs to be done often. My advice is to do refinement each day for an hour, just pick the top stories from the backlog and improve their quality. But don't over do it, refine only a bit more than what the team thinks can fit in a sprint.


To make refinement easier, it's common practice to agree on the quality of the work item in a definitoin of ready. Keep in mind that, just like the definition of done, it is not the purpose of the DoR to be an equivalent of a checklist. But a list of quality requirements.

And one last important aspect of refinement is for the members of the refinement: come prepared. Take some time before refinement to read the work items that are going to be refined, formulate questions or even collect some information up front. In the end it is always about delivering the right product increment the customer asks for (which is always more important than following procedure)