For an agile team, all scrum ceremonies (known as “events” if you’re a SAFe enthusiast) are equally important to effective software development. Each ceremony has a purpose and reason.
Daily stand-ups resynchronize the team’s activities every 24 hours. Sprint planning brings the team together to examine what user stories they can commit to for the next two weeks while the sprint review gathers the team and stakeholders together to demo working software and assess progress. Finally, sprint retrospectives provide the team a safe space to discuss not what they did but how well (or poorly) they did it.
Backlog refinement however stands alone as a key ceremony. Why? The backlog refinement ceremony, while equally important, is the only component that can severely impede team performance. Good backlog refinement provides the fuel for an agile team to keep them flying straight and fighting the battle of scope versus time.
When the product owner gathers with the team to refine the backlog, they examine what user stories are candidates for the next two weeks. Next, they determine if the team has the capacity to take on the proposed user stories. A dialog within the team and with the product owner underscores this process. Bargaining is normal as the team converges on a decision. Experienced product owners leading this process have a demanding job because they develop their own practices and principles to help them succeed.
How to Elevate Your Backlog Refinement
- Make backlog refinement about the future not the present.
- Focus on knowledge transfer not knowledge presentation.
- More “what” and less “how.”
- Use time to test quality and speed progress.
1. Make Backlog Refinement About the Future, Not the Present
When an agile team executes, sprints, or iterates, it’s consuming user stories and creating working software or work products. Those stories are a present reality for the team’s two-week timebox. The team did the backlog refinement for these present stories in the past.
Future stories, that is user stories the team may likely take up in the next sprint, need to be ready to review in the upcoming sprint planning ceremony. If they’re not ready, the ceremony will take longer, the planning quality outcome will diminish, and the team will limp into the next sprint. Therefore, the more future stories are ready for review the better the selection universe for planning.
Well, that sounds easy enough but not so fast.
First, the definition of “ready for review” can be complicated. A minimal definition would include a meaningful title, good description, acceptance criteria and a provisional sizing, if we’re using points. Of course, there’s the constant question of how much detail, beyond these basics, a product owner should put into a user story.
So how far out into the future do you refine your backlog? The answer is: as far as you need to.
Second, how many stories we need for upcoming sprint planning is not always easy to calculate. Depending on team throughput and upcoming scope complexity this could vary significantly. For example, if a team has been cranking out eight user stories per sprint, with an average size of five points, then a 40 point velocity metric becomes a good gauge. The product owner and team would focus on refining about 40 points worth of user stories. If you’re not using points, then story throughput becomes the gauge and eight stories per sprint is the metric. At a minimum, having one sprint’s worth of user stories, eight in this example, would represent a near future focused backlog refinement process.
Beyond the minimum, conventional wisdom in agile recommends at least two sprint’s worth of stories, or in mathematical terms, N+2. Achieving N+2 is challenging and may even be impossible in some contexts. However, it’s worth every effort because N+2 provides a team breathing space and flexibility in planning.
So if N+2 is good why not N+3 or N+5 or N+8 or N+20?
Simply put, the future is never as clear as the present (or near present). The challenge is balancing near-term scope fidelity with longer-term scope uncertainty. Going too far out into the future risks returning to waterfall mythological assumptions that you can know the future with certainty. Of course, you don’t want to focus only on the present, either. So how far out into the future do you refine your backlog? The answer is: as far as you need to.
2. Focus on Knowledge Transfer Not Knowledge Presentation
During backlog refinement the product owner presents to the team a set of user stories to refine. At best these stories contain good titles, great descriptions, well-written acceptance criteria and supporting documentation for both business and technical context. At worst these user stories have only a title and the rest is in the product owner’s head needing to be written out and discussed in real-time with the team.
It is easier to present knowledge than to transfer it.
In either case, the product owner then presents the first or highest priority story and the team discusses their understanding and asks questions. The team repeats this process until they refine all the stories. The session ends. The next sprint planning session takes some or all of the refined stories and the sprint starts.
As the sprint progresses the product owner begins to field question after question about these stories that should have been asked during backlog refinement. The nature of the questions show a lack of understanding of not just who the story is for but what it intends to accomplish and why. This slows the sprint down significantly and results in stories escaping the sprint. Not a good thing. What happened?
It is easier to present knowledge than to transfer it.
Knowledge transfer is a next-level practice for backlog refinement. Any product owner can present information but it takes skill and focus to ensure knowledge transfer and secure acknowledgement. This is not a simple thing to do but here are a few ideas to help.
Be Obsessed With Form
Make sure every user story is written in one of three forms.
A meaningful title provides a starting point for understanding but a great description crisply communicates the who, what and why. We do this by using one of three standard user story formats. This doesn't mean the form is the only written information put into the user story. Again, how much detail to put into a user story is always up for debate but at a minimum, use the form.
-
User story form: (As a <ROLE>] I want to <GOAL> so that <BENEFIT>.)
-
Job story form: (When <SITUATION> I want to <MOTIVATION> so I can <OUTCOME>.)
-
BDD form: (Given <CONDITION> When <TRIGGER/EVENT> Then <OUTPUT>)
Shared Tasking
If you can assign the story to a developer in the backlog refinement session, have the developer write out or share the headline tasks he would do to execute the story. Time estimates are not important at this time. If the story can't be assigned, ask for a volunteer or the team as a group to do the same. See the figure below for examples.
Acceptance Clarity
Consider the Given <CONDITION> When “EVENT/TRIGGER Then <OUTPUT> form for your acceptance criteria. The Gherkin language has evolved to support BDD and TDD development methodologies and is helpful when writing acceptance criteria.
3. More ‘What’ and Less ‘How’
The ideal user story communicates what needs to be done with enough detail to allow developers to produce working software. A user story is about solution intent not design specification. There is constant tension on how much detail to put into a user story. That tension is not always easy for us to navigate at first.
A simple rule to keep in mind is that good (or even great) user stories are more “what” than “how.” Leaving the how details to the developers rather than spelling everything out ensures user stories don’t morph into programming specifications. It also provides developers with creative space to design solutions.
4. Use Time to Test Quality and Speed Progress
Backlog refinement sessions range in duration from 30 minutes to two hours depending on need. A simple time rule tests whether the story is too vague, unclear, spawning too many questions, or the conversation becomes more design solutioning than functional comprehension.
Set a timer for 10 or 15 minutes. If the product owner and team can’t come to a consensus that the story is ready for work in that amount of time then it's too undefined or complex to continue refining. Move on.
Next level backlog refinement is a characteristic of high performing teams. It helps teams maintain a sustainable pace, but with breathing room. While challenging to achieve, these four keys will set you up for success.
This article was originally published on TonyTimbol.com.
