During sprints, Scrum teams work on the items in their sprint backlog. Since the purpose of the team should be to deliver value, their focus should be on completion of the items they have committed to.
However, there is more to think about than only the current sprint. Teams are expected to prepare the product backlog items that they will work on in later sprints as well.
Refinement is time spent during the current sprint discussing and elaborating product backlog items so that they are ready for future sprints. The importance of refinement is underestimated by many teams, which is a pity since it has some nice advantages.
Unfortunately, many teams do not unlock the full potential of refinement.
Not only is the time spent on refinement often limited, but many of the refinement meetings I join are inefficient.
I meet teams that spend half the meeting watching the product owner entering the new backlog items in the workflow system. Although they estimate the user stories afterward, little time is left to discuss the best solution and risks that need to be avoided.
Often, user stories are owned by one developer who is regarded as the expert, and other team members are not really involved and focus on their own user stories instead. Again, little time is spent on exchanging ideas in order to come up with a better solution.
I coached a distributed team where half of the team worked abroad. “Since our team members sometimes have problems with the language of the requirements, we read the user story aloud during the online refinement meeting,” the product owner explained. “This way we all get involved and have the same understanding of the backlog item.”
This seemed like a waste of valuable time. I explained to them how to increase their impact: by seeing refinement as a process, not just as a meeting. In a process, the backlog item is sliced, and a solution is proposed, reviewed, and discussed. Refinement becomes a series of activities like thinking, writing, reviewing, discussing, and preparing.
“Preparing?” Several team members in the room chuckled. “We do not prepare our refinement meeting.”
It is crucial to allot enough time for preparing your refinement. You can do this as a team, but I think it is fine when one developer or business analyst takes the lead in defining a user story and proposes a solution.
If you see refinement as a process, this can be done way before or in between two refinement meetings. This way other team members and even stakeholders have enough time to get involved. When they have trouble with the language, they can read the user story at their own pace and give it a thought. These thoughts can be shared and discussed by email, in virtual whiteboard meetings, or during the next refinement meeting.
There is no better way to gain clarity than to ask questions, so I came up with 18 example questions for team members to consider that should trigger refinement discussions.
If you did not prepare for your refinement meeting, you can select any question from the list and gain better insight into the desired solution. If a question seems irrelevant, skip it.
If you like to prepare, you can also use these questions to involve participants who are otherwise reluctant to speak their mind or who are less involved. Ask them to select a question and prepare the answer ahead of time. This way they come to the meeting prepared, and you can discuss their opinions and answers.
Depending on context and the type of user stories you are working with, other questions can be more suitable than the ones listed here. If you have suggestions, please do share them.
I am Derk-Jan de Grood and these are my agile-thoughts
2021 © Leiden, South Holland, NETHERLANDS by Derk-Jan de Grood
Derk-Jan de Grood works as agile transition coach for Squerist. He has worked for organizations like ING Bank, RTL, DPD, Nationale Nederlanden and Greenchoice and supported them in their Agile Transformation.
Derk-Jan have written several successful books and is currently working on his next one on delivering value in complex organizations.
Experienced trainer, workshop host, and regular (keynote) speaker at Agile and Software Development conferences in Europe and America.