John Hines' Code Blog

A blog on Agile software development and Scrum

  Home  |   Contact  |   Syndication    |   Login
  35 Posts | 6 Stories | 33 Comments | 0 Trackbacks

News

The information in this weblog is provided “AS IS” with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.

To err is human, to forgive is divine.

Tag Cloud


Archives

agile

Sunday, August 09, 2009 #

The real beauty of Scrum is that it gives you the tools needed to know very quickly when things aren't going well.  The most important part of Scrum is running successful sprints.   You can't expect to have a successful project with the majority of your sprints not meeting their goals.  The primary tool for measuring your sprint's progress is called a burndown chart.

Simply put, a burndown chart tracks how much work you have left to do in your sprint.  In its most basic form, an empty burndown chart looks like this:

The Y axis tracks the amount of work you've committed to finishing.  The X axis tracks the amount of time you've given yourself to finish the work.  The "Ideal Trend" line represents the best rate of progress - a steady, sustainable pace.

There are diffent styles of burndown charts, but if we add the number of tasks, progress, and work remaining for a perfect sprint, it would look something like this:

The number one job of a Scrum Master is to do everything possible to help the team finish the tasks by the end of the sprint. It's not to make every sprint look exactly like this. If you're just starting to use Scrum, you'll see a pattern similar to the next three burndown charts.

A typical first sprint vastly overestimates what the team can accomplish. I'll let the psychologists figure out the why, but it's a pattern I've seen again and again. I'll note that the places where the progress line is flat are either weekends or some technical issue. Here's a typical first sprint's burndown chart:

Beware! This is a pattern that can occur anytime the team has taken on too much work. Any Scrum Master who sees this happening should immediately focus on fixing this trend.

Depending on the Scrum Master, the second sprint tends to underestimate. There's a lot that goes into kicking off a project. It's typically safe to commit to a little more than what you got done for the first sprint, but no team wants to miss their goals for the first two sprints of the project. Typically the Scrum Master ratchets down the amount of work to ensure that positive status report:

In my experience it takes around three sprints to find the right balance of work to commit to. The amount of work is usually between that committed to for the first couple of sprints and the team is generally more productive.

You might be asking, if my project takes less than three sprints (six weeks in my world), is it worth using Scrum? If the small project involves less than five people I'd advise against it. Scrum is great for complex projects but it's not required for all of them.

I'll end with an example of one common mistake: The mid-sprint adjustment. Now, it's no problem to add stories to a sprint in progress. But it is a mistake to add work A) too soon or B) too often. The best sprint planning is to get the amount of work right in the planning meeting. But yes, I've done this:

Scrum Masters know that the burndown chart is their best friend. Review it at every stand-up meeting. Take it out to breakfast. But whatever you do, don't ignore it.

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati