Ending the never ending Product Backlog Refinement tweaks
A hard reset towards the ideal Refinement Process
The description according to the Scrum Guide: 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 Guide ‘20
Almost every Retrospective the topic pops-up as something we can improve on, this ‘act’ remains one of the biggest challenges for most of the Scrum Teams I have been working with.
Sure we have tweaked the length of the session, the timing of the day, week or Sprint, we’ve had discussions about who needs to join when, you name it, we have probably discussed it. Although I am not dismissing the need for discussing possible tweaks and adjusting your meetings and processes when you think it adds value, I do want to challenge you to, instead of introducing tweaks, to start with a blank sheet. A hard reset so to say.
We all know that as time progresses processes tend to become longer, bulkier and more complex, therefore I suggest you STOP introducing tweaks, go back to the drawing table and discuss the ‘ideal Refinement process’ with your team.
Do I now have the holy grail ready for you? Absolutely not. However! I do want to share the ‘going back to the drawing table’ process which we have performed together to help the team gain ownership of the process.
Get your team together and start at the beginning.
If you have read some of my previous articles, you know, I always start with WHY.
The first main question I have for the team is: WHY do we have Refinement and what is the goal we want to achieve? I give everybody the opportunity to answer the question in order to collectively create one overall goal. By asking these questions it also gives me, in the role of Scrum Master, the opportunity to manage false expectations such as; the goal is to throw a number on the stories, we have to give the Product Owner the estimation so he/she can plan the sprint for us. Plus, asking the WHY questions also serves to challenge the team on how much ownership it’s taking around their Refinement process.
Once you all agree on the WHY, the purpose of the Refinement and expectations have been managed, you can move on to the WHAT.
This suggested ‘hard reset’ doesn’t mean you have to dismiss whatever we have been currently doing, it would be a waste to try to reinvent the wheel. Work together with the team to write down the overall process by asking them what do we currently do and/or need to be doing before, during and after the Refinement?
In order to increase the feeling of ownership I make sure that everybody gets the opportunity to write down their own perspective of the ideal Refinement process. I therefore like to use the 1–2-all technique (depending on the group-size). I split the group into smaller groups of 2, give them the assignment to individually answer the questions; what do we currently do and/or need to be doing before, during and after the Refinement? After the silent writing assignment they discuss their written stickies in pairs of two, in order to bring a consolidated process towards the rest of the group. Every group brings their process to the rest of the group and we discuss together which step belongs where. As a Scrum Master, challenge the team on the impact vs. effort of their process so we don’t over complicate things. Do we NEED to have this step, or is it a nice to have? What happens if we don’t include this step? How much time do you expect to take during this step?
As a final step, in order to get group consensus, I end with the question: good enough for now and safe enough to try?
Once you have the overall process in place you can move to the HOW; How do we organise the meetings?, how do we gather the necessary information & how do we inform each other?, which information do we need from who?, who is overall responsible that the Refinement happens? You can use the Miro-board to colour coordinate the stickies/steps of the process and make sure that ownership is clear. Further challenging questions can be: The stories need to be ‘clear’? → What does clear mean?, when it’s not clear how do you get additional information? Who is responsible for getting that additional information?
Exemplary outcome of the end result of the session;
Side-note: every team, of course, adds different kinds of details, most of the recurring themes are the following:
Before the start of the Refinement meeting:
Reading the epic/story to gain a base understanding of the topic.
Questions:
Is the hypothesis clear, do we understand the WHY?
Do we need additional information from the stakeholder?
If yes, invite the stakeholder to the Refinement or write your question down the comment of the Jira-ticket.
Can we break it down so we can incrementally add value?
If yes, which slicing technique will we use?
During the Refinement:
Welcome the stakeholders and give a brief explanation of the meeting & goal.
Provide introduction about the epic/story
Discuss the WHAT; for example: in/out scope, risks, assumptions, required skill-set, dependencies
When necessary; discuss any questions that you already have identified
Slice the epic when necessary and provide estimations and discuss the differences.
After the Refinement:
Are the agreements clearly stated in the Jira-ticket?
Do we need to proactively discuss the decisions with the Product Owner?
Are there outstanding questions documented?
Is the stakeholder tagged in the Jira-ticket?
Side-note: In the beginning it acts as a check-list but as the team gets more and more into the habit of using it, it will no longer need to actually use this list.
So, did this whole exercise ended the ‘never ending product backlog Refinement tweaks’? The answer is yes and no. It surely helped the team to create clear expectations as to what is expected from whom during which stage of the Refinement process. It also really helped the team with creating full ownership of the process and therefore, as a Scrum Master, I hear it less and less as a main topic of debate during retrospectives and I experience it’s because the team has taken ownership of their OWN created process and has found new ways to introduce adjustments to the process by asking themselves the question after each Refinement; What went well, what do we need to improve for the next Refinement?
After all it still all comes down to creating transparency, in order to inspect and adapt.
