Story time workshops not backlog refinement

Backlog refinement workshops can be one of the most unproductive meetings in Scrum. And they're not even an official Scrum event. Let's see what we can do to improve them.

The trouble with backlog refinement meetings

Imagine you're the Product Owner on a Dynamics 365 project. The team is several sprints into the project and things are going well. The backlog has shrunk in some areas because the Scrum team has deployed the first solution package into production, and its grown in other areas because the users have come up with some great new ideas for future releases.

By now your backlog is a mess. There are duplicate stories. New stories with inexplicable titles or no acceptance criteria. It hasn't been ordered in a while.

The Scrum Guide says that the Scrum team should spend up to 10% of its time refining the product backlog. So the team calls for a backlog refinement meeting and you stand in front of a display for two hours in front of a groaning team failing to unmess your mess.

After another couple of sprints suffering through refinement meetings, the Scrum Master suggests adjusting the team's future capacity to account for the unproductive time spent in meetings.

If that's your backlog refinement meeting, stop it. Now.

Try story time workshops

Here's a better practice that's been working for my teams: story time workshops.

Story time workshops are much more enjoyable than backlog refinement.

Story time workshops are much more enjoyable than backlog refinement.

In story time, the Product Owner doesn't sit with Visual Studio trying to update the backlog in front of the development team.

The Product Owner unmesses the backlog in Visual Studio in private, on her own, outside of the development team's glare. If she needs help or ideas, she can get help from the Scrum Master.

In fact, use Visual Studio as little as possible. Find a whiteboard and sketch out some ideas. Take a photo and tidy up the story in Visual Studio later. The workshop is about in-person collaboration not live documentation.

The whole development team doesn't attend story time. Just the Product Owner and the minimum number of developers needed. The Product Owner can bring along a subject matter expert to help with the details. The only developers that attend are the ones passionate about the upcoming stories.

The story time calendar is posted in advance somewhere near the Scrum board so everyone knows what's story time sessions are coming up.

It's between a few minutes and an hour, at most. It covers a few related stories. It's not two hours trying to fix the entire backlog.

The Scrum Master's role in story time workshops is to ensure that they are short, produce good quality stories, and that the right people are there.