Backlog Refinement Sessions
Backlog Refinement¶
The purpose of this meeting is for the team to review the prioritised items in the backlog before accepting them. We will make necessary adjustments for clarity and estimate the effort it will take to complete each Backlog Item (BLI).
Refinement sessions help to accumulate a shared, comprehensive understanding of requirements among the dev team reducing the level of unplanned rework.
As a result of the refining activities, the next chunk of backlog items is ready for delivery meaning that it has the necessary level of transparency for its accurate implementation.
Desired Outcome¶
The outcome of the backlog refinement is a list of BLIs that should be clear to all team members and be ready to be implemented in an upcoming Sprint.
Later, at the Sprint planning event, the team agrees a set of BLIs for the Sprint and plans the tasks it will take to complete them.
Attendees¶
Ideally, the entire team will attend a Refinement sessions, this includes developers, testers, product managers, and UX when required.
Prerequisites¶
The team lead and product manager will groom the backlog prior to refinement, this may include:
- Engaging with key stakeholders to gather requirements
- Removing BLIs that are no longer relevant
- Prioritising the BLIs
- Review BLIs that are ready for refinement, ensuring that there is enough to understand the resources involved to complete it
- Prior to refinement, a list of BLIs that are due to be refined will be made available for the team. It is recommended that team members review the list prior to the meeting
Agenda¶
Backlog Item Discussion¶
Discuss what needs to be done and how it needs to be done to satisfy the acceptance criteria. When discussing BLIs the team should:
- Ensure Acceptance Criteria is valid
- Review dependencies
- Review order of work
- Create / Review tasks
Decompose Backlog Items¶
Items must be sized appropriately. This means that they can be realistically "Done" within the Sprint time-box. If discussions reveal that a Backlog Item is unclear or high level and complex, the team should break it up into more precise and detailed BLIs to better understand and estimate them.
Estimate / Planning Poker¶
Everyone in the team makes up their mind about the estimated effort for the BLI, typically we will be estimating using Story Points. When ready, they simultaneously reveal their estimates. If the estimations differ within the team, the members discuss their concerns until they reach an agreement.
If the agreement still can’t be reached, the facilitator, can go with the highest, the lowest, or the most common estimation. But a better way is to remove this BLI from the current agenda as most probably it needs to be reworked
Guidelines¶
Here are some tips to ensure the success of the refinement session.
Keeping on track: Timeboxing Discussions¶
- Discussion on a single BLI will be initially limited to 10 minutes
- If the BLI is still deemed unclear, we will move onto the next item
- Any questions regarding the BLI should be recorded, answers to these questions will be gathered by the team lead and product manager
- The BLI in question will be adjusted accordingly and brought back into refinement later
Psychological Safety¶
Refinement sessions are meant to discover requirements collaboratively. Conversations are so important because they forge BLIs into concrete tasks and items of the backlog. So, invest more in discussions and motivate the participants to express any concerns they may have.
- There are no stupid questions
- Everyone is entitled to an opinion
- Every member of the team is free to express their concerns
- Estimates are not promises, we are providing our best educated guesses!
Build on feedback¶
A good practice is to consult the former Sprints within the production process. How much cost and effort did previous items take to be completed?
Development is a team sport¶
We have the freedom and flexibility as a team to decide how we want to work. This document is a guideline for how we could handle our refinement sessions - if something isn't working well, or we can improve in some way, the team should feel encouraged to speak up!