If your Agile team is like most others, you begin every backlog refinement session “from the top.” You discuss the work items that will start next and work your way down the list.
Always doing it this way is a big mistake!
With this short-term focus, you risk:
- not understanding the big picture
- forgetting to plan the medium-term (the following few months) activities
- suddenly realizing that the efforts of items deeper in the backlog are surprisingly large
- not noticing complex dependencies among the backlog items
These issues can seriously impact your delivery schedule of important work. But there are effective ways to avoid these problems. And in this blog post, I will give you the medicine against this. Three practices that have proven super-effective.
Improving your backlog refinement ceremonies
Your backlog refinement ceremonies are crucial for effective Agile (the best teams have them weekly). It’s when your Product Owner, together with the developers, improve the quality of the backlog.
By structuring the sessions in the typical way I described above, you focus on the most important items at the top of the backlog: the ones that are going to start in a few weeks.
This “just-in-time” refinement is effective. By specifying the details of the user stories just before starting work on them, everything is still fresh. Plus the why of the story, and the value delivered, is also more accurate.
So, it is perfectly fine to structure the sessions this way most of the time, but not always. Mix it up sometimes to avoid the risks above. There are great alternatives.
I will now present you with three great alternatives. Practices that will save you from the surface-scratching, short-termism, and tunnel vision that leads to nasty surprises.
Why not try one in your next backlog refinement session and see for yourself?
Read more about backlog management
1. Scan’n Plan
Have the team and the Product Owner scan through the complete backlog. I recommend you do this once a month.
For example, if the team is doing backlog refinement at a regular one-hour session every week, a Scan’n Plan session could take 30 minutes of one of these sessions per month.
This is how you do it:
The team scans through the backlog, top to bottom. For each item, the team quickly (within a minute or two) considers the following questions:
- Is the item too low in the order of priority? (If yes, raise it higher)
- Is the item still necessary at all? (Items may lose their value for all sorts of reasons)
- Is the value or customer need uncertain?
- Is the item dependent on something? (Interface spec, prototyping, UX specification, other kinds of dependencies)
- Is the item size uncertain?
Your goal is to clean up unnecessary items, confirm the priority order, and flag items which would benefit from spike-like attention before they progress too far up the priority order.
Checking the value and uncertainties of an item is more important for new items. The Product Owner can figure out a labeling practice to focus the Scan’n Plan effort on the fresh items on the backlog. The priority check is valid for all items.
The “Plan” part of Scan’n Plan means that the Product Owner and the team can use some of this time to update the high-level plan for the coming months. This could mean updating a major feature release plan, or it could mean looking at a longer-term roadmap to see if any new items need to be added to the backlog.
2. Guess the Effort
Exposing the uncertainties around an item’s effort can be achieved with a “Guess the Effort” (GE) session. In a GE session, the team plays planning poker for all unestimated items on the backlog. Do this without any discussion whatsoever. The resulting variance of estimates can be a signal to focus spikes on these items.
The GE session is a quick way to add a rough effort estimate for the complete backlog. This is useful for creating crude estimates on a release scope.
Use spikes as insurance
Spikes should be used to follow up on the items that the Scan’n Plan or GE practices have flagged as interesting. The spikes are an insurance – the team must balance investing effort in spiking versus getting hit with unmanageable surprises.
3. Splitting Squads
Splitting work into small enough chunks is more important than estimating the amount of effort. Good Agile teams find ways to split work effectively.
Splitting backlog items in the regular backlog refinement session, with the full team present, is not a good idea. Splitting work requires analysis, thinking, and time. You should not rush or time-box it.
You would be better off doing the splitting separately, outside the refinement session.
One possibility is to do It as part of disciplined preparation, as I describe in this blogpost. If you, in a refinement session, discover that you need to split an item, it is a good idea to assign the splitting to a Splitting Squad.
A Splitting Squad is a team of two or three persons who take on the task of splitting an item into two or more chunks of work. There is no upper limit to how many pieces you can split it into.
I personally once had an item that my team tried to develop as a single story. After failing miserably, we realized that we should have split it into 20(!) smaller stories.
Why a squad of two or three persons?
More brains have more viewpoints. Besides, two people have twice the discipline. If you leave the splitting to a single team member, it will be harder to follow up. Taking an example from golf: If it rains, a single-player cancels her tee time. But even in a downpour, you don’t cancel if you are playing with a friend.
The members of the Splitting Squad should be agreed as part of the Scan’n Plan session. Do not leave the session without agreeing on who follows up.
Use these three practices for better efficiency in backlog management
The three practices of Scan’n Plan, Guess the Effort, and Splitting Squads will help any Agile team experience fewer surprises, better schedule accuracy, and better-sized work items.
These practices great tools to add to your backlog management toolbox.
Published: Nov 15, 2022
