Story Time! The Hidden Scrum Meeting

Is your team having difficulty forecasting when a project will be completed? Do you have a large number of un-estimated Stories in your product backlog? Are your planning meetings several days long and full of confrontation? If so, it could be that you’re forgetting to “groom” your product backlog.

Ken Schwaber generally advises that the team should dedicate five percent of its time (every Sprint) to preparing the backlog. This process is generally known as backlog “grooming” or “maintenance.” Here’s a good definition of what is involved:

“There are many things that one does to the backlog in preparation for future work. One adds new stories and epics, one extracts stories from existing epics, one sizes, adds benefit values, and so on.” -Dr. Dan Rawsthorne, CST

I’ve recently worked with several clients that acknowledge Schwaber’s five percent recommendation, but don’t actually follow it. That is, they understand that they need to spend five percent of their time on grooming the backlog, but they fail to do this and, as a consequence, their planning meetings become tense and drawn-out.

For several years now, I’ve advocated explicit backlog grooming as an integral part of the Scrum process. That is, I advise teams to establish a regularly scheduled, recurring meeting that lasts for two hours every week. It’s an opportunity to discuss and groom the backlog, so the planning meeting can be as efficient and productive as possible. I call these meetings “Story Time” meetings. This is hardly a new concept. When I worked exclusively with XP teams several years ago, it was common practice to hold a regular Story Time meeting. Although they are not a formal part of Scrum, I’ve found that Story Time greatly improves project planning and reduces confrontational planning meetings, which are all too common for many teams.

A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work. This may include adding new stories and epics, splitting up overly large stories, and sizing.

So if Product Owners and Developers on your team spend the majority of planning meetings arguing over semantics, consider how Story Time meetings could streamline forecasting. I’d love to hear how it impacts your day-to-day business.

Download the PDF version: Story Time_The Hidden Scrum Meeting blog

Posted in Agile
4 comments on “Story Time! The Hidden Scrum Meeting
  1. Victor Szalvay says:

    I’m glad you aired this. Our team does a single Story-Time meeting per two-week sprint. It does in fact help to stream-line the planning meeting process. I also agree that the Story-Time meeting should be made an explicit part of Scrum (add to the books as formal part of the process).

    On the flip side, some team members have voiced a concern with the shear quantity of meetings given a two-week sprint (Sprint Planning, Daily Standup meetings, Detailed requirements sessions, Story Time meetings, Sprint Demo meetings, etc.). Looking at the list, I can sympathize, but unless someone comes up with a way to communicate via telepathy I think we’re stuck having to set time aside for face-to-face communication.

    I would take the productivity benefits of a healthy Scrum environment (meetings and all) over the alternatives.

    Great article.
    — Victor

  2. Tobias Mayer says:

    Victor, I get around that problem by introducing the idea that these are “work sessions”, i.e. part of development. Language can change the way we think. I posted something about this to scrumdevelopment recently, here:

    This was a great post Kane, an important on. I agree completely that the Story Time meeting should be considered part of “standard Scrum”.


  3. Jason Lewis says:

    I have generally referred to this as story scrubbing, but I also feel like there is a problem with some other practice…most likely with on-site customer (or the customer proxy role), customer driven priority or story writing in general.

  4. Michael James says:

    I like to do the same thing using a subset of the team for the first half of the meeting, usually the Product Owner plus key people who are particularly interested in requirements and skilled at splitting epics.

    Then bring the whole team in for the estimation portion.


    Michael James
    Software Process Mentor

Leave a Reply

Your email address will not be published. Required fields are marked *