Lessons from leading scrum: it’s not a race

Posted on Aug 6, 2009 in Blog | No Comments
Lessons from leading scrum: it’s not a race

In my time as a scrummaster, some of the teams I worked with struggled to deliver the user stories we committed to each sprint. We had a bad habit of signing up for nine or ten stories, delivering two or three fully, and carrying the rest into the next sprint to finish the couple of days of work that we didn’t complete. It was maddening, and made release planning extremely difficult and unreliable, as we couldn’t count on any estimation of our team’s velocity.

Eventually, I decided to step back from the details of an iteration and focus instead on the patterns of how we worked. I watched in planning as we did everything technically right. We lined up the user stories we wanted to execute, decomposed them into tasks, and then triple checked that our estimates on the task cards fit into our actual available time. We even factored in some time for the unknowns that would crop up. By all measures, we were primed for success.

The next morning’s scrum revealed the problem clearly. One by one, we all stepped up to the board and pointed to a task card that we planned to work on that day. And each team member pointed to a task card related to a different user story. One person even pointed to two small tasks on two separate user stories.

On the first day of our iteration, our team of seven started eight different user stories. At the end of that iteration, all eight of those user stories were incomplete.

Our problem? We were approaching our scrum board like it was one of those carnival games where you shoot water canons at targets to make your horse/hot air balloon/clown/whatever charge toward the finish line. As soon as the starting flag waved, we each grabbed a cannon and plugged away in isolation, hoping that our horse/hot air balloon/clown/whatever would cross the finish line before time ran out.

We had a couple of mental model problems with how we approached our process:

  • We assumed 100% success at all of the user stories we planned to execute, so we made no effort to maximize the amount of success for the what-if scenarios.
  • We saw a single finish line at the end of the sprint, so we did nothing to try to fully complete stories before that deadline.

Like most process problems, understanding the issue was ten times harder than fixing it. The solution was obvious: make every effort to limit the number of user stories in play at any given point in the iteration. Focus on pushing a story through the process completely—all the way to acceptance from the product owner—before starting a new story.

If we focused three or four water cannons at one target, we’d push our horse/hot air balloon/clown/whatever past the finish line quickly, and then we could tag team another target.

So what about your team? Are you aiming at as many targets as you have team members, or are you controlling risk by keeping the number of stories in play to a minimum?

Image from http://www.flickr.com/photos/northfield_mn/ / CC BY-NC-SA 2.0

Leave a Reply