by Lisa Mabli, Managing Agile Consultant
What does it look like to do Backlog Refinement the right way? What I mean by that: Imagine if at the end of an hour there are about a dozen newly estimated stories in your backlog, and the scrum team has about two sprints worth of small, estimated stories in their backlog.
If you have ever experienced Sprint Planning that takes hours to complete, or a Refinement session that felt like an endless, unproductive swirl of questions without answers and ultimately no estimates on new stories, then read on for you – and your team.
The Principles of a Proper Refinement Session
There are four key principles that drive a proper Backlog Refinement. They are:
Principle #1: It should not be painful.
Many scrum teams dread the idea of attending a refinement session, and in many cases it’s totally understandable because the main input – the backlog – is not actually ready to be looked at yet. That just leads to wasted time in the form of discussions that do not move the team in a forward direction or yield a backlog of stories that are sprint ready, and that creates frustration all around.
Principle #2: It should not be used as a substitute for architectural and/or design discovery.
Big architectural and/or UI/UX decisions should be made at the feature level well in advance of a Refinement session. A good target is to craft features that represent 1 – 3 months of work for a scrum team, and make sure a feature is “ready” – meaning there is very little discovery left to do – about a month ahead of time. This allows a couple of sprints to write stores with clear requirements, and present them to the scrum team at least one sprint ahead of when the work will be started.
Principle #3: It should be crisp and efficient.
Twelve stories per hour – 12 sph – is your target refinement velocity. That’s five minutes per story. If the team can’t get to a comfortable estimate in less than five minutes, the story isn’t ready to be refined. Send it back to the PO and move on to the next story in line. Have a plan for the session. Know what the intended outcomes are. Eliminate swirl and over-solutioning.
Principle #4: It should be based on realistic expectations and a clear “Definition of Ready.”
As a team, don’t expect bunches of stories to be estimated if the requirements and/or priorities in the upcoming story backlog are not clear. Set the expectation with one another that Refinement will be a valuable session, and work together as a team to ensure that it is not a waste of anyone’s time.
A clear Definition of Ready is also a must – otherwise the conversation about sending stories back to the PO for further work will be a very hard one to have. Come to a common agreement about what “ready” means. If nothing else, start with “if we have so many question that we can’t get a good enough estimate on it in five minutes, it’s not ready.”
Principle #5: It should be discussed in every Retrospective.
Sometimes, things don’t go as planned. People aren’t perfect, and neither are scrum ceremonies. Use some time in your Retro to evaluate how you can improve your Refinement sessions so that the team can get to have two sprints’ worth of estimated stories in their backlog.
Putting It All Together: Backlog Refinement should be disciplined and outcome-oriented.
Discipline and goal-setting is critical to having successful Refinement sessions that your team will actually begin to look forward to. It’s not impossible! Have an agenda, insist on only introducing clearly defined stories, time-box discussion to five minutes per story, and agree to send stories back for more work if there are too many unanswered questions.
Backlog Refinement Basics
I love a good refinement session! It’s really amazing to watch teams work through the estimation process on small, clear stories like a well-oiled machine. But to get there, it helps to make sure everyone understands what the session is, and isn’t, supposed to look like.
What it isn’t
Here are some things that are what I like to call “bad.” The Refinement session isn’t:
- The first time a PO has thought through requirements or priority
- The first time architectural questions have been addressed
- The first time the team has seen a story or its parent feature
- An opportunity to swirl endlessly about the intended outcome (requirements) of a story
- An opportunity for solutioning
What it is
And here is what the Session is meant to be. The whole point is simply to provide an opportunity for the team to:
- get good enough clarity on the intent of a story to give a good enough relative estimate for planning the sprint after next
- knowledge share between PO and development team in order to get better at crafting and estimating stories
That’s it!
Message to Product Owners: Don’t come to refinement with an unclear idea of what the intended outcome is for a story. The Dev Team isn’t psychic, so if you don’t know what you want, they certainly won’t know what you want. It’s a lot of responsibility, but it is your responsibility to make sure that the inputs to the sessions are high quality inputs. You know what they say: garbage in, garbage out.
Message to the Dev Team: It’s okay to ask questions, in fact it’s expected. That’s kind of the whoe point. But please don’t over-solution! We are problem solvers so sometimes it’s hard to put on the brakes and be comfortable with some unknowns. Get used to the discomfort. You just need to have a rough idea of how you might implement the thing and what potential risks there are. Save the solutioning for later.
Roles and responsibilities
Who is responsible for a successful refinement session? The whole scrum team, that’s who. Here are some of the basic roles and responsibilities that will help ensure you have successful Refinement:
PO’s contributions
- A healthy backlog of good, small “Ready” stories that are
- Listed in priority order
- Averaging <= 3 SP
- Independent
- Crystal clear
- Decision-making authority. Whoever is presenting stories in Refinement should be the person who can make a decision about them. If a question needs to be escalated for a decision, it’s that person who needs to be in the room.
- Clear vision of the intended outcome of the story, including mock-ups as needed
Other contributions
- Scrum Master: enforcing the Definition of Ready by timeboxing the discussion to 5 minutes per story (use a timer!)
- Development Team (Dev + QA): knowledge of requirements, an idea of how they might be implemented
- All: risks and dependencies already identified, major questions already answered
Rapid Refinement Tips: Tactical Advice
Always:
- Have a Definition of Ready and Definition of Done
- Come to Refinement with a backlog of small, clear, prioritized stories (2 sprints worth!)
- Time-box discussion to 5 minutes per story, reject if Definition of Ready is not met
- Dedicate as much time as needed during the sprint to catch up or maintain a backlog of about 2 sprints worth of estimated stories
Nuts and bolts:
- PO can own the calendar invite
- PO starts off with a brief overview of the upcoming stories
- Find a time-keeper
- Start with the first unestimated story on the list
- Work down the list until the session ends
Rapid Refinement Tips: Where to go from here
Start small with:
- Creating a Definition of Ready
- Getting good at Gherkins
- Fine tuning relative estimation skills
- A backlog that has two sprints’ worth of work prioritized
- Answering architectural and design questions much further upstream
- Stories representing the outcomes of conversations rather than conversation starters in refinement
Watch out for:
- Over-solutioning
- Accepting stories that are not “ready”
- Voices not being heard (remember the rules of relative estimation as a team)
- Unclear goal for the session
Refinement was successful if…
All team members understand the requirements and the implementation just well enough to provide a reasonable story point estimate for enough small stories to fill up two sprints with work.
Watch my recorded livecast of this content below, and the preceding session “Sprint Planning in 30 Minutes or Less” here!
Lisa Mabli is a Managing Agile Consultant at LitheSpeed.
Get in touch with our team for Agile coaching or PO training.
