When teams adopt Scrum, they often start with the obvious processes: The development.
Translated into Scrum, this means: "Planning" at the beginning of the Sprint, Daily Standups every day and "Review" and "Retrospective" at the end of the Sprint. This is all correct, but it assumes that there is another process before planning. After all, good requirements do not come forth on their own, but are usually the result of a team of requirements engineers and product owners who elicit and refine these requirements and then submit them for development.
Refinement is used to ensure that planning does not become a chaotic handover point between requirements managers and developers.
The Refinement serves to refine and estimate requirements to bring them to a maturity level, which satisfies the definition of ready. In other words, the requirements are ready for implementation.
Since refinement is a popular topic in all my trainings, I would like to share my collected tips for setting up a refinement with you:
- Make it a regular meeting
- Organize it in a way that it does not get in the way of developers daily work (e.g. no full-day workshops.) If you need more time, meet more often, e.g. 2hrs each week.
- You can clarify requirements with single developers, so it does not occupy the whole team. - But for refinement include the whole developer group, as the refinement also builds understanding and shared knowledge. Especially when it is not yet clear which developer will implement which requirement, a broad understanding of the requirements is important in order to move forward quickly and in an agile manner in the implementation phase (sprint). This also allows dependencies in the group to be identified at an early stage.
- Use efficient agile estimation techniques like Planning Poker or T-Shirt sizing for less detailed items.
- Have some buffer between refinement and planning, to deal with clarification or other upcoming issues (Don’t make refinement the day before planning, it does not work out well – been there done that)
- Theoretically, you can do all things you do in refinement also in the planning meeting - but in practice, it's usually better to do as much as you can in refinement and only refine/estimate in planning if something important is still missing. This way you can focus on refinement and estimation in refinement and during planning – well – focus on planning, capacity and dependency management, which is already enough.
- Depending on the amount, you can also split the refinement into multiple sessions. (also depending on time zone availability, if you are working globally)
- If there are people involved, that are needed only for a small fraction of the meeting (e.g. subject matter experts for specific topics), make it a "we will call you on demand" meeting for them to save time. This way these people can be called in on demand and leave again, once their issue is solved. This way they can productively use the time for something else, while still being available for possible questions that block the team from progressing. This usually strikes a good balance for both sides.
- Some items can go through multiple refinements, and also get multiple estimations. If items are in a very early stage, you can still estimate them with more inaccurate, but faster techniques, like T-shirt-sizing or magic estimation to give the Product Owner & stakeholders a first idea of the effort. Early estimation minimizes waste, as a Product Owner can decide at an early stage to stop detailing a requirement, when it is clearly too much effort with too little value coming from it.
- Do a very short feedback session at the end of each refinement to see if people think it was worth their time. Gather feedback and collect possible improvements from the group. 5-10 minutes at the end of the meeting are often enough