Backlog Refinement (formerly known as Grooming - but evidently that word means something different in some countries) is the least structured of the Scrum Practices. Backlog Refinement can get messy!
What makes Backlog Refinement feel uncomfortable? What can we do to make these sessions run smoother?
Backlog Refinement meetings have 2 main purposes:
Clarify requirements
Prioritize the work
Simple right? Where does it go wrong? Let’s take a look at where Backlog Refinement goes astray and what you can do about it.
Clarifying Requirements. In the old days, business partners wrote their requirements down, compiled them into a big document and then passed them off to the development team. There wasn’t much collaboration and as a result, we had delays and Frankensystems. Getting requirements defined collaboratively takes some talking, and there isn’t a neat process for that, at least not yet!
If you are thinking “well the Product Owner decides”, then I wonder if you are working in a real organization. Most organizations have multiple stakeholders for any given feature, not to mention the people who can determine its technical feasibility.
Here are some typical Backlog Refinement Pitfalls:
Pitfall #1: The team talks in circles.
The team goes around and around, arguing about how the features should behave. So much information is thrown into the mix that no one can see through the clutter.
What can you do? I recommend Dialogue Mapping to keep a handle of the information being shared and decisions made.
Pitfall #2: The requirements/user stories have outside dependencies that the team can’t control
When you have a user story that needs work from outside parties, it can really screw you up because their priorities may not align with yours. My advice here is not to start anything until you have the pieces you need from dependent teams. “But we want to get ahead of the game”. No, you’re not getting ahead, you are creating waste. Write a placeholder story for the dependencies and once it’s complete, you can work on your story. Otherwise, you end up with a bunch of half-done stories and nothing valuable to show for it.
Pitfall #3: The right people are not in the discussion.
We need information from a subject matter expert, but they aren’t available. Again, don’t work on it. You’re going to have to revisit it all over again, it’s waste. Get the people you need and then have the discussion.
Pitfall #4: Our user stories are too big
“We wrote this nice story but then the developers told us it was too big.” Appropriate sizing is something that teams learn over time. There’s no formula for the right size. You’re going to have to split it. Here’s a great little chart about story splitting. Story Splitting Chart I’ve had teams split a single story into 400+ stories. I asked them “what would have happened in waterfall?” The answer, “It would have taken a year to do that single requirement.” A year of darkness!! Split it up and now we can get feedback.
What have you encountered in your Backlog Refinement sessions? Let us know in the comments!
