Scrum Guide: 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.
Scrum does not prescribe ‘refinement’ as a scrum event to have in the calendars of participants of these refinements. It is a simple, yet sufficient framework for complex product delivery. Sometimes it prescribes a lot of structure, but in this case it gives minimum boundaries. I believe in self-management and not too much structure. But in this case, I want to plead for more prescription.
In my opinion refinement is too important to not structure as a fixed event in everybody’s agenda. To me, this moment - in which you detail out backlog items - is the most tangible evidence that scrum is not an IT exercise but Is it joined effort by business and IT.
If there is 1 moment where you collaborate closely with process owners and SMEs, then that moment is refinement, because the whole idea of this momentum is that the scrum team understands what business wants and why they want that.
When we moved to use Scrum, refinement became one of the most productive meetings as we had a team taking time to discuss the "how" instead of having a single developer deciding on the solutions. That increased motivation, feeling accountable for "your ideas" and knowledge sharing. Also developers finally know "why" so they can feel the purpose/goal of their work.
Same goes for the stakeholders. It helps to build a good cooperation and understanding as people tend to not write everything in tickets, but if you talk to them and ask "why's" you can come up together to different conclusions and change direction
This means that you depend on the availability of a wider group of people and if you don’t put a fixed moment in your agenda to discuss refinement, you may run the risk of not having enough stories ready for the next sprint.
What are the benefits of scheduled refinements?
The people you need are available and you don’t waste time searching for slot which will suit everyone
- Fixed refinements help to structure the week so that also the Product Owner knows when the stories should be ready for refinement
- Stories that are ready for refinement will be properly visible in the backlog so that the scrum team and stakeholders know which stories will be refined
- Product Owners do not disturb the team with unplanned meetings to refine stuff Also if you want to check something with developers which is not urgent you can wait until next refinement and can inform stakeholders when you have an answer to their request
The consequence of not fixing the moment you refine is that you may spend a lot of time refining during sprint planning. That has the backside that you need to hurry to be ready before the next sprint, while the end of a sprint is already very busy and stressful. At that moment the scrum team is super busy with preparing the review, having the review, making a plan for the next sprint, task the stories and start that sprint.
What is the impact to the quality of the scrum teams work? If you also need to spend a lot of time refining at the apotheosis of the sprint, it could lead to rushed refinements of stories that are not fully understood.While I plea for a fixed event, what can we do to make it not another boring, non-engaging meeting?
First of all, it is key that the Product Owner is very well prepared and fully understands the business needs so that the stories are really ready for refinement. The Product Owner can add and adjust stories anytime, but during refinement, we only discuss stories that are completely ready for refinement. Nothing is more boring than waiting and watching a person type in a story in Jira. It can be very frustrating and demotivating for developers to be on the meeting when the Product Owner doesn't really know why or what is needed.
This Product Owner’s knowledge of backlog items is a result of good communication and cooperation between the PO and stakeholders and the conversations they have before the story is refined with the scrum team.
During refinement, the developers conclude that a story needs to be split, for example because they know they need a background story before they can do the front end work. If a story needs to be split into smaller parts, don’t let the whole team wait and watch the person who is sharing the screen doing it.
One team member can manage it in the background while the rest of the team discusses the part you decided to have in the first story. Once that part is refined you can move smoothly to the next story which contains the things you have removed from the first story.
Moreover, a timekeeper is needed to keep us focused in an inspiring and not too rigid way. There are very nice and funny techniques for that, which we may blog about in future.
Another way to keep everyone engaged is to use break out rooms. Also Zoom and Teams have nice features to break out with the possibility to freely walk in and out of a room. Although it is a team effort to understand the upcoming work, sometimes it is really not useful that everyone is involved in refining all stories and breaking out can be very refreshing.
You need to be absolutely sure that you have enough stories that are well understood by the team (= meeting the Definition of Ready). Therefore I recommend to make Refinement a predefined event of maximum 4 hours per week. The scrum master ends the event on the moment that you have enough stories for the next iterations. This is to avoid that you meet, just because the meeting is on the agenda.
What are your thoughts about this topic?