Agile Toolbox: 10-minute story time

Backlog refinement meetings can become unrewarding and tedious really fast if you have to work through 20 stories in two hours. Wouldn’t it be nice if there was a format where a team could use its full energy while at the same time upping their flexibility in planning? I think there is, and I like to call it story time. In short, a story time is a daily 10-minute timebox after the daily standup that is used to refine exactly one backlog item. I’ll explain the basic rules as well as some advantages and disadvantages based upon my experience with it.

The problem

Usually, a Scrum team blocks roughly 10% time of their sprint for backlog refinement. This amount of time was once advocated as an upper limit in the Scrum Guide, but has been removed now for some time. Still, it is quite present. In my experience and that of my colleagues, this is mostly done within one or two  meetings that last one or two hours in a two-week sprint.

This meeting is mostly known under the term “backlog refinement” meeting. There is also the term “backlog grooming” to emphasize the fact that a backlog needs to be groomed like a garden. This naming has been largely abandoned as its name is a little too close to cyber-grooming . I always liked the name “story time” best. Coined byKane Mar , it beautifully shows the focus on telling customer stories instead of solution tickets. A team with which I moved from a classic 2-hour refinement to this new format connected the name “story time” with the new format. It helped them separate the two formats; since then I’ve been introducing the new format to teams as story time.

The PO will discuss backlog items with the team in a normal backlog refinement meeting. The story will be told and the item is worked on until it fulfills the team’s definition of ready (DoR) . Ideally all colleagues are constantly engaged in discussion so that all aspects of the topic can be brought up. In reality, though, some team members contribute to some stories, some to others and some keep quiet most of the time. They may participate in estimation (if practiced) but otherwise abstain from the discussion. This is usually the main reason why those meetings are perceived as tiresome, inefficient and sluggish. On top of that, it is not uncommon that the last items in the timebox get rushed through because everyone just wants to get it over with.

In order to understand the workings and see if this could be optimized, I’ve tracked the time during some of those meetings for each story. It turns out that most of the items generlly took slightly less than ten minutes. One discussion later there was the first experiment for a ten-minute story time meeting and many more would follow.

To keep those meetings short and efficient, I usually start with a very restrictive rule set. As soon as the teams have had the chance to gather some experience with the format, some small adjustments are made, in other words: inspect and adapt .

The rules

1. Every day after the daily there will be a 10-minute story time slot. This ensures that there won’t be an extra meeting in the team’s calendar. Since the team gathered for the daily, they are active and energized enough for a ten-minute session.
2. Exactly one item will be discussed per session. If the team finishes early, rejoice and move on.
3. If it looks as though the timebox won’t do for the current issue, have a break issued by a timekeeper (e.g. the Scrum Master) after about eight minutes. Use the last two minutes to gather the questions/todos/research needed to get this story ready. Write those items on the card/into the ticket and solve them asynchronously before continuing this topic in a later story time session. Alternatively, if the presented story is clearly too large, you may use the timebox to simply split it into multiple smaller stories and use later story time slots to go over them piece by piece according to your priority.

Benefits

There are immediate and obvious benefits for the PO. She gains a lot of flexibility and speed in dealing with stakeholders and their new ideas/issues as well as newly uncovered information. This is because she can plan anew each day which story to refine next. A common issue with only occasional refinement meetings was a story uncovered right after the last meeting in the sprint. Even with a high priority, such issues had to either be refined in a planning or pushed to a later sprint. Story time now enables the team to at least talk about it and see if it is ready and can be planned for the next sprint.

Another benefit is the endless energy that is released. Even after a fully utilized daily of 15 minutes the combined meeting time won’t exceed 25 minutes. Unlike long meetings with a lot of context switches, this can be accomplished without losing a relevant amount of energy. Speaking of context switches: one of the major reasons for wasting energy is completely eliminated compared to longer refinement sessions, since only one item will be discussed. This goes very smoothly with the idea of a sprint as a focussed timebox since there is no additional meeting anymore. The asynchronously gathered information between story times also eases the pressure often perceived by the teams to discuss a story out of the blue.

Some caveats

As with most tools, story time is not a silver bullet. There are some drawbacks. Many items that belong together have to be refined over several separate days. This can lead to some redundancies in the ensuing discussions, some facts will be uncovered a couple of times over. If the backlog is very fragmented, the team might forget certain facts that have not been explicitly written down (which is a necessity anyhow). The same thing does happen in big refinement meetings as well but tends to be overlooked. On the other hand, this beautifully shows where there is still implicit knowledge and silos, which in turn should be addressed, made transparent and be worked upon with utmost urgency.

Bigger topics cannot be refined from start to finish in such a small timebox. There are at least two ways to deal with those. For bigger items the story time can be used to split those into smaller stories. Those can then be refined in further installments. If we are talking about really big topics like themes, major epics and such, it usually makes sense to have a separate workshop to get a grip on the topic before diving into multiple story times (e.g. kick-off, story mapping, lean canvas, …).

It can feel challenging for a PO to decide which item to work on. However, this aspect usually doesn’t matter so much in daily business due to the higher cadence of the story time meetings. It rather takes pressure off the PO since she can just tackle the other story on the next day.

Conclusion

So far, every team that had previously worked with classic refinements has given enthusiastic feedback after their first story times. The benefits by far outweigh the caveats. The POs love the flexibility and the team members rejoice in more focus time during their sprints.

This article is part of a still loosely connected series dubbed “Agile Toolbox”. I’ve put the links to more articles down below. If you have any questions or experiences with this format, or something similar, please let us know. If you happen to have stumbled over a topic you would like to read more information or stories about, leave us a note. We’ll be happy to tap into our vast combined experience to share it with you.

Other articles from the Agile Toolbox:

• Eventstorming meets Domain Driven Design with Alberto Brandolini
• Mob programming and shared everything
• Retrospective on the value stream of your software delivery

Image sources:

• Foto by Andrea Piacquadio from Pexels
• Foto by Thirdman from Pexels
• main image by fauxels from Pexels
• my own drawing