Join the Mastering Agility Discord community
Many teams that I've worked with struggled to make backlog refinement an ongoing activity. This made these specific teams reactive rather than proactive in terms of dependencies, which rendered them less effective to capitalize on newly arising opportunities to create value or lower risk. If anything, more risk was created due to the inability to effectively refine Product Backlog Items (PBIs) before they were needed. In this article, I shed a bit of light on backlog refinement.
Backlog refinement is not an event in single-team Scrum
First things first: in single-team Scrum refinement is not an official event. The Scrum team is accountable for the entire product, from conception til the point that it is decommissioned. The Nexus framework on the other hand (working with 3 to 9 teams) DOES have refinement as an official event, due to the cross-team dependencies. To deal with these dependencies, refinement is needed to ensure the relevant teams know what to expect from each other and when. Note that it is not timeboxed, yet takes as much time as needed. For this article, we will assume we're working with an independent Scrum Team, therefore referring to refinement as an ongoing activity rather than an event.
Backlog refinement can happen whenever. Technically, all events in Scrum are in place to make all other meetings redundant. The timebox for the Sprint Planning is 8 hours, which provides quite some time to spend on refining items for this Sprint or the next. However, this might leave you with too little time to work with dependencies (be this people or resources) when refining for the coming Sprint.
I've worked with teams that used the Sprint Planning as mentioned, as well as with teams that planned a few hours every week to refine, took some time after the Daily Scrum to refine 2 or 3 PBIs, or even used the Sprint Review to create some break-out sessions with the relevant stakeholders to talk through and refine relevant work.
In these meetings PBIs were discussed in terms of expected value/outcome (i.e. details), size, order, and potential dependencies identified. Dependencies were limited as much as possible to ensure the autonomy of the Scrum Team.
Who attends refinement?
Ultimately, the purpose of refinement is to ensure that the developers have enough information available to turn it into a Done Increment.
A common misconception is that PBIs should adhere to the Definition of Ready. The Definition of Ready does not exist. Here's how 'Ready' is mentioned in the Scrum Guide.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
That's it. Creating a Definition of Ready to act like a stage gate ("we have to have all the boxes checked before pulling anything into the Sprint Backlog") is shooting yourself in the foot. If there is sufficient information available to start working on a certain PBI, and you're fairly confident you can pull it off in a single Sprint, you're pretty much good to go. You'll learn by doing.
If there's only a single person who should be able to clarify the PBIs and remaining questions by the developers, it would be the Product Owner. The Product Owner might not know every single detail of every PBI, but he/she at least knows where to get the information needed. It's a utopia to expect someone to know anything and everything in detail. So the Product Owner wants to surround himself with the right people with the right information, available at the right time. Tricky? Yes. Does it pay off? Absolutely!
You can add more people to the conversation and maybe even leave the Product Owner out, depending on the impact and details of the discussion. You also might not need the entire team there. A single developer, with the Product Owner and the user/client/Subject Matter Expert (SME) might suffice (and saves a whole lot of money compared to having the entire team present).
How much time is needed?
Being a consultant, I reserve the answer to everything to be:
"It depends".
And it really does in this case. There is no single answer to it, as it depends on so many factors. To name a few:
- Present skills in the Scrum Team
- Understanding of the Product
- Dependencies
- Connection to stakeholders
- Acceptance Criteria
- The ability to place PBI in context
- Relation to Product Goals
- How near in the future the PBI would be picked up
And why the latter, you ask? Great question! Let me explain. Here is an example of a fairly refined Product Backlog.
The top PBIs have been refined to such a granularity that they fit into a single Sprint and the developers are confident they can pull it off with the information available.
The further you go down the Product Backlog, the fewer details there are. The grey items have little to no details. Depending on Sprint length, it may even be reasonable to remove them from the PB in general.
The pink items have slightly more details, but not more than, for instance, dependencies that have been identified so that a plan can be created to work with those dependencies. Let's say the team will need Cindy (who holds very specific knowledge) in 5 Sprints from now, the Product Owner can already approach Cindy to ask her to keep her agenda open for the Scrum Team to work on these items. The same would go for instance with software access, needed hardware, and so on. Doing this upfront leaves you with some time to work with fallback options if it doesn't work out the way you plan initially.
As you may imagine at this point, it's hard to put a single number on how much time should be spent on backlog refinement. However, there's such a thing as spending too much time.
After the point where the blue line crosses the black line, the quality of the discussion will start to deteriorate. When working in complex domains, where empiricism is applied, there are more things unknown than they are known. This means that spending too much time discussing the items at hand, is the same as trying to look in a crystal ball. We can't predict tomorrow's weather with 100% accuracy today either. Get enough details clarified so you can at least start working on it, with a good idea of when it's done. You can figure out the rest as you progress.
Learn by doing
As with all things in Scrum, there is no single right way of doing refinement. You'll have to find out what works for you and for your team. This process, too, lends itself to inspection and adaptation. The more you do it, the better you'll get at it. But please, promise me that you'll continue to invest the time to do proper refinement in order to make your product thrive.
If It Scares You, it Might Be a Good Thing To Try.