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.
Note: My older articles are available on my personal blog at http://KaneMar.com
| Attachment | Size |
|---|---|
| Story Time_The Hidden Scrum Meeting blog.pdf | 137.14 KB |
Kane,
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