Have you ever been in refinement with your whole team only to find three people doing all the talking? After a few minutes of this, you might wonder if you need to be in this meeting. The scope seems to be rapidly expanding, and the conversation now pivots to scope and budget.
Your thoughts wander back to that pull request you were almost done submitting. Then one of the client stakeholders brings up some internal barriers to completing that work. They will need to go work with people on their end to get those resolved before that work can start. That confirms your suspicion. You drift back to your work while they continue ironing things out.
In an ideal situation, a product owner would know exactly what work they want to add to the backlog. They would have clearly-written and appropriately-scoped stories. This work would then be elegantly prioritized and shared with teams. They would have a brief conversation and be off running.
In reality, product owners often don’t know the technical complexities of the work they want completed. Or they want help visualizing what it could look like. That “simple ask” might take up far more of the budget than they anticipated. Conversations open up around clarifying work and identifying optionality. And all these conversations take time to work through with the right people. This is where pre-refinement comes in.
What is the goal?
Front loading refining work to a smaller group of people. Not everyone has all the context. Getting together the right people can clarify work, improve the quality of stories, and save you money. When pre-refinement is successful, teams spend less time on each story during refinement.
Who is involved?
The person empowered to determine what work is going to be done. People who can help this person make informed decisions about the scope and priority should also be there. This often includes some combination of product owner, key client stakeholders, a designer, a tech lead, a delivery dead, and a quality analyst.
Hint: if you notice anyone not having a lot to add for several meetings in a row, they probably don’t need to be there. Or at least not as often.
How often should we hold Pre-refinement?
Start by letting your product owner drive the conversation. Have them explain what they want. If it isn’t already captured as a story, have them write it there in the meeting. Tech leads and QA can ask questions about what to include in the acceptance criteria. They can also bring up complexities and dependencies. Designers can better understand the user workflow and identify upcoming work. This often leads back to more questions from QA or the tech lead as they clarify their understanding.
A client stakeholder might bring up client-side dependencies impacting the release timeline. Pre-refinement provides a great place to talk through those so that everyone is aware. You can prioritize and scope work according to these constraints. Collectively, this group writes stories. These then go into the runway of work or get kicked back if they need more information or design.
Once work has been clearly defined and designs are completed, these stories can then go to refinement. In refinement, the product owner can give synced explanations of each story. This allows for streamlined conversations with devs. They can ask targeted questions. You can refine stories without bogging down in conversations that only pertain to a few people.
What is the Value Proposition?
There are benefits when looking at cost, time management, and skill distribution. Folks can make more effective use of their time by scoping pre-refinement and refinement. Plus, each discipline can lean into its strengths and have more consistent workflows. Does your client love blue-sky thinking? This gives them a space to have these ideas captured without taking the entire team down that path.
If a product owner is new or inexperienced, these meetings provide a great opportunity for targeted coaching. Similarly, this can be a space to coach client devs and help them build their understanding of technical architecture and tech stacks. Team leads and the client can also discuss timelines and how they impact release planning. All the while, devs can focus on feature work.
Interested in exploring other practices you might adopt to improve your Agile processes? Check out the series Rethinking Agile. And, stay tuned for the second part of this series on scrum ceremonies to add to your sprint, where we’ll talk about demo prep.