Teams don’t do enough product backlog refinement. Yes, it’s a sweeping statement and yes there are teams where this isn’t true but for the most part I feel it’s a common problem for new and existing teams. All the coaching for Scrum talks about a team using 10% of their time for refinement. If you work a 40 hour week that’s 4 hours per week, 8 hours per 2 week sprint. Is any team going to want to sit in meetings for this length of time? This blog explores one technique I’ve used to make refinement an easier experience for all.
I’m not questioning the value of refinement, its fundamental to the machine that is scrum. In the past I’ve set up 2 two hour meetings per week to do refinement. This ticked the box in terms of hours but I didn’t feel that it produced the value we needed. The team would still enter sprint planning and come up with more questions than I’d like. Of course some questions are expected but the volume of questions was slowing progress in planning. The length of meeting was draining for all involved and by the end it always felt like we were going through the motions rather than discussing anything of value.
It started with a retrospective
We discussed this in a retrospective and someone suggested we trim these formal refinement sessions down to an hour each. This wasn’t to get more time back doing work; they wanted to do something different with their refinement. We called it “at desk refinement”. A team member, sometimes a couple, would catch up with the PO informally and talk about a story. They would then use the time to do any technical research they needed. This might be just 15 minutes for a single story but it was highly valuable. The team was involved in software development with testers and developers, initially the developers were the proactive ones working with the PO to understand the stories. Quickly the testers wanted to be involved so we ended up using the Three Amigos approach to refinement, still not as a formal meeting just at whoever’s desk made sense.
In the formal meetings the PO and the team member would initiate the discussion based on what they learned, more questions would come up but the overall time to collective understanding was reduced. This was revolutionary, the sprint planning became much more streamlined, the team were refining items for the next couple of sprints. Side note, this didn’t mean those sprints were locked in terms of scope; it just meant there was enough understood so that priorities could shuffle when needed.
I have seen teams spend too much time refining stories, its less common but can happen. They have a formal refinement meeting, then the team work on additional research, planning, designing, maybe even some code. By the time they get to sprint planning the work is basically done, while you cannot question the industry, they should have been working on something in the current sprint, getting the work in progress finished.
It’s easy to fall into bad habits for good reasons
Back to my team who have initiated a great refinement process. A few sprints later and the wheels fell off. Nothing in the backlog was ready for sprint planning, which then became a slow painful session again. What happened? Well, the team had become a little complacent. Doing in sprint work had taken priority a couple of times, PO and team members postponed the informal refinement sessions to a later date, which meant they were not done. As a result, we were not covering as much in the formal sessions.
I raised this in a retro and the team was honest, they knew the work took priority and because the next sprint was well refined they took the call that they could catch up on refinement later. Of course later never came, they were behind as soon as they missed a few sessions. A project manager (yes we still had them, but that’s another story) said something very telling, we had stopped fuelling the machine.
I’m going to jump on this analogy now and run with it. A Scrum team is an engine, it needs a few things to keep it running. Scrum masters and agile coaches put a lot or effort into the servicing side, retrospectives, inspect and adapt, all that good stuff. But the fuel that it burns is user stories, if the fuel is not refined enough the engine will splutter and choke.
Final thoughts
There are other approaches to refinement, one way is to take 15 minutes after the standup for a single story alongside the formal sessions. Figure out what works for your team to generate that collective understanding in an iterative and incremental manner.
Everything I’ve said so for doesn’t really answer the question that is the title of this blog. Why is it so hard to do this? The process I’ve described relies on the team and the PO being proactive, interested and responsible. Things most people in good teams will be doing all the time when it comes to the sprint backlog. The trouble lies with them seeing the refinement as a first class citizen of work. They usually feel the work they are doing now is the most valuable thing, and it is, of course it is. But it doesn’t mean that the refinement should be forgotten. As a coach it is your responsibility to build this understanding into the team. They need to fuel the machine with refined fuel not the lumpy crude oil that enters the backlog initially.