Even though it’s not an official meeting according to the 2020 Scrum Guide, Refinement is conducted by most teams. So what is the value of this extra meeting?
During a Backlog Refinement we take a look at the stories in the product backlog. We estimate if the size of the story is fine or if it should be split. Should some aspects of the story be refined or additionally clarified? Which stories are candidates for next sprint? What options exist and what does the team say to them? We watch if the team has the right understanding of the stories. If refinement is done on regular basis, we have an always up-to-date backlog and the sprint planning becomes easier.
With the proper refinement, you avoid a story not being taken into the sprint by the team. Refinement is also the time to give the team a perspective and outlook on what new stories came into the backlog that the team may not have seen since the last refinement.
Crucial factors in Backlog Refinement
The duration of this ceremony is 1 to maximum 2 hours. It should be a steady, reoccurring part of the calendar, only to be cancelled when there really is nothing to discuss. In my opinion, the whole team should be there if it is in any way possible. The PO is the moderator of this ceremony.
The PO should go through the Backlog before refinement and sort it so that the priorities are correct. If changes are necessary, they can be made during refinement. The whole team has to understand the backlog and each story. This works well when you go through the backlog story by story. The team is able to ask questions immediately and those questions are documented for future handling. Once a story has been discussed, you usually don’t have to look at it in such detail the next time.
Have the important information available at hand
This involves having all possible information ready for the team to understand the story in the context of the overall product complexity. It is important to listen to the team and take their remarks into consideration because in the end, the story is there for them.
In many teams, we also made the estimate during the refinement and did not wait until later. If we are already able to estimate the story points for a story in the refinement, we are able to split a large story into smaller ones early on. This saves time in the next refinements and plannings.
Where do most mistakes happen concerning Backlog Refinement?
When the complete team is not there
Let’s say only the architect or specialists join the refinement and not the whole team; then it’s possible to lose the overall comprehensive view on the topic. This can result in the team going into the planning less prepared and the problems only being addressed there. If the refinement had been done properly, it could have saved time and costs.
The team says that a story is not ready
The team might not commit to a story in Planning based on a lack of information. This can lead to conflicts between the team and the Product Owner. This conflict could be avoided through regular refinements.
Some tips for a successful refinement
Estimating stories in refinement
This has proved to be an effective, time-saving tip. I haven’t always done this with all teams in the past, but it’s such a good practice that I now do it all the time.
Tracking of questions about stories
In the past, we did not track questions very thoroughly. As a result, it was not clear which questions had been answered and which were still open. We have found that tracking questions is a very good reminder of what needs to be clarified before a story can be planned into a sprint.
Working with comments in a tool like Jira
Comments are important to record the discussions about a story or to answer questions asynchronously. But if there are too many comments, it takes too long to read and it is difficult to determine the real status of a story. I have now started to update the description of the story to keep it up to date. This helps the team and myself.
Use of relevant resources
If there are relevant external resources on wiki, or some diagrams, they should be recorded in the story, e.g. via a link to be able to look it up more quickly.