4 Key Tips on doing Next Level Backlog Refinement for Product Owners: Part 1

by Tony Timbol · Published June 22, 2021 · Updated July 1, 2021

All Scrum Ceremonies, Events if you’re a SAFe enthusiast, are equally important to effective software development for an agile team. Each 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 2 weeks, the Sprint Review gathers the team and stakeholders together to demo working software and assess progress, and Sprint Retrospectives provide the team a safe space to discuss not what they did but “how” well or not well they did it. Backlog Refinement however stands alone as a key ceremony. Why?

The Backlog Refinement ceremony while equally important is the only one that can severely impede team performance. Because good Backlog Refinement provides the “fuel,” ready for work user stories, for an agile team to keep flying and fighting the battle of scope versus time.

When the Product Owner and the team gather to refine the Backlog, they examine what user stories are candidates for the next 2 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 occurs underscores this process. Bargaining is normal as the team converges on a decision. Product Owners leading this process have a demanding job. Experienced Product Owners develop their own set of practices and principles to help them succeed.

Below are Four key tips, examples of practices, that can elevate backlog refinement to the next level. Product Owners who want to go from good to great and keep their team’s flying high may consider adopting one or more of these.

Make Backlog Refinement about the future not the present
Focus on knowledge transfer not knowledge presentation
Draw the line between What and How
Use time to test quality and speed progress

Make Backlog Refinement about the future not the present

When an agile team is executing, sprinting, or iterating, it is consuming user stories and creating working software or work products. Those stories are a present reality for the two week timebox the team is in. Backlog Refinement for these present stories was done in the past.

Future stories, that is user stories that the team may likely take up in the next sprint, need to be ready to review in the upcoming sprint planning ceremony. If not ready the ceremony will take longer, the planning quality outcome will be diminished, 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 points are being used. How much detail, beyond these basics, should a product owner put into a user story is a constant question.

Second, how MANY stories are needed for the 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 been cranking out 8 user stories per sprint, with an average size of 5 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 points are not being used, then story throughput becomes the gauge and 8 stories per sprint the metric. At a minimum, having 1 sprint’s worth of user stories, 8 in this example, would represent a near future focused backlog refinement process.

Beyond the minimum, conventional wisdom in agile recommends at least 2 sprint’s worth of stories, or in math terms, N+2. Achieving N+2 is challenging. May even be impossible in some contexts. However, it is worth every effort because it 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. Focusing only on the present is not recommended. So how far out into the future do you refine your backlog? 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, supporting documentation for 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.

In either case, the product owner then presents the first or highest priority story and the team discusses their understanding and ask their questions. This is repeated until all stories are refined. The session ends. The next sprint planning session takes some or all of the stories refined 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 is intends to accomplish and why. This slows the sprint down significantly resulting 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 meaning full title provides a starting point for understanding but a great description crisply communicates the who, what and why. This is done by using one of three user story formats that have become de-facto standards. This does not mean the form is the only written information put into the user story. Again, HOW much detail to put into a user story is a constant question but at a minimum, use the form.

-User Story (As a “role” I want to “goal” So that “I 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 the story can be assigned to a developer in the Backlog Refinement session, have the developer write out or share the headline tasks he would do to execute or complete the story. Hour estimates are not important at this time. This is tasking in community for transparency and confirmation of understanding. If the story cannot 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 use the Given “condition” When “trigger/event” Then “output” form for your acceptance criteria. The Gherkin language has evolved to support BDD and TDD development methodologies and is helpful when used in writing acceptance criteria.