9 questions you should ask during refinements
Published:
From my experience, refinements are rarely used as working meetings but rather as meetings in which the PO tells the team what they should do next – but that’s not agile.
Refinements should be thought of not as meetings but as part of the actual product work.
Here are some questions that developers (and other team members) should ask during refinements that from my experience work as great conversation starters:
1) Why?
The most important question – if not answered by the PO already – is: “Why should we do this?”. The team should question every requirement and fully grasp what the story is about before starting the implementation work.
2) Can I rephrase the requirements in my own words?
Another great start into further discussions: Rephrasing the requirements in your own words helps to change the perspective and make sure that everybody is talking about the same thing. Mostly this question leads to adjustments in the story description or the ACs.
3) Is this a requirement we can automate in the future?
Sometimes there are requirements like “change the text / image” that actually could be automated in the future with just a little more work. It might make sense to change the story accordingly to make sure that this is the last requirement of this kind.
4) Can we look into the relevant code parts together?
Mostly, people think that this is nothing that should be done in the refinement. But it is actually the best way to think about appropriate solutions to the requirements.
Does this story touch other code parts that need further discussion? Are there any refactorings that could be done while working at this part of the application? Does everybody understand what’s actually happening in the code?5) Are there any dependencies?
An often forgotten question: Is the implementation work dependent on other teams / persons / licenses / timings? If so, how can these dependencies be eliminated? Do we need to write another story for these dependencies or could they be solved during the implementation work?
6) What’s the best way to work cross-functionally on this?
Does it make sense for designers to pair with developers? Or for strategists to give an introduction? Think of possible ways of how to actually break down the story into work packages and how these work packages should be phrased in order to allow for aligned and transparent work on this issue.
7) Can we slice this?
In 50% of the cases, the answer to this question is “Yes”. To cite the Agile Manifesto: Maximize the amount of work not done. Meaning: It’s always better to have multiple simple stories instead of one bigger one.
8) Does this need a Spike story?
If all these questions still don’t make you feel more comfortable around the topic, articulate exactly that. Try to find out what the unclear parts of this story are. If this is something that would exceed the refinement meeting it’s mostly a good strategy to phrase a spike story. Write down all the questions that you have in that story and put it into the next sprint.
9) Can I summarise what we want to do in this story?
The last question should always be: “Can I summarise what we discussed in the last few minutes?” With this you make sure that the story is fully understood and that there are no open points that need further discussion. If any of the above, this question should become part of your refinement routines.