Online burndown chart generator

One of the aspects of Scrum is its focus on transparency - getting all information out in the open. And one of the areas that enables the transparency is the burndown chart. It's a public posting of the progress of the team throughout its current sprint.

On the horizontal axis you see the days of this sprint. The vertical axis describes the amount of work. At the top of the vertical axis is the number of "ideal man hours" we committed to for this sprint. The straight diagonal line is the "ideal burndown" that we're aiming for. The slightly less straight line is our actual burndown. As you can see this chart is from somewhere during the third week of our four-week sprint and we're slightly above target. But things don't look as desperate as a few days before, thanks to some colleagues getting back from Holidays (which it says in the small scribling that you probably can't read).

As a Scrum master I like to post this information as publicly as I can. So just having it on the wall of our team room isn't good enough, since there are many people that don't visit our team room. Ideally I'd like to have the burndown chart projected on a wall in the central hallway of our office, so everyone can see it first thing they come in in the morning. But as a nice step along the way to this, I chose to publish the chart (and the rest of our product backlog) on our project wiki.

In the first sprints I did this by taking a photograph of the burndown chart every morning, right after updating it. I'd then upload the photo to our wiki. The only problem is... uploading them every day turned out to be too much of a hassle. So the wiki actually only got updated once a week. And that's not good for transparency of course.

So this time around we went searching for a simple tool that would lower the threshold of updating the burndown chart on our wiki. We searched for an extension to MediaWiki that allows you to create a chart by just entering the numbers in your wiki text. That turned out to be quite a challenge. There are many charting and drawing extensions for MediaWiki, but they either didn't do what I wanted or we couldn't get them to work on our wiki.

In the end I just gave up and wrote a simple web page that -when fed with the right parameters- will return a PNG image of the burndown chart. You call the page like this:

• burndown.jsp?days=1,2,3,6,7,8,9,10,13,14&work=200,170,165,150,125,95
  

And the page will return the following image:
So the days parameter indicates the day numbers shown on the bottom. I entered all of them for the entire sprint right away. The work parameter is the work remaining. I just entered the values that I know, which is why the green line stops halfway through.

The generated chart is really simple and not very pretty. But it is very easy to keep up to date and that's what counts most. I just add the remaining hours at the end of the URL every morning... and that's it.

Although I consider this generator a stop gap solution until I find something better, I imagine it might also be useful to other budding Scrum masters. For that reason I've put the page online for public use at http://apps.vanpuffelen.net/charts/burndown.jsp. Just click the link and you'll get some usage examples.

Let me know if this generator is useful to you in the comments section. Also let me know if there's something wrong with it and I'll do my best to fix it.

Update (January 1st, 2010): in my company we've created a custom version of this same tool and used that in many projects over the last few years. This public burndown generator has drawn over 60.000 charts in 2009 alone, so apparently we're not the only ones who use burndown charts. That's why I've now updated the tool with the best features that we've added over time at my company. Check the latest version on http://apps.vanpuffelen.net/charts/burndown.jsp for all the features and let me know what you think of them.

My first game of planning poker

Yesterday I took part in the first sprint planning meeting of my life. We have started up a new development project and we decided to use Scrum as the process. The project is actually quite small, so we have just two developers (myself included) and a product owner for it.

The product owner had prepared nicely and had a quite extensive product backlog. He had even filled in a "how to demo" field for a lot of the stories, which I'm not sure he's supposed to do before the sprint planning. At least it wasn't very handy to have the "how to demo" in place, as it makes it harder to discuss alternative solutions for the same functionality.

After the product owner had explained each story, we were to come up with an estimate of how much work (in ideal man days/story points) it would be to implement the story. I have done many of these estimation sessions before, but this time we decided to play a game of planning poker. Being the good scrum master that I am, I had brought two packs of (rather improvised) planning poker cards.

The other developer and I talked through the story, determining what it would take. We were basically already breaking the story down in tasks, which was a nice head start for the actual breaking down we planned to do later. After agreeing on the tasks, we would go into our poker deck and select the card matching our estimate. When we both had selected a card, we'd pull it out of the deck at the same time - revealing our estimate.

Now I must admit that I wasn't too impressed with the transparency that this estimating method brought. I guess -just as with real poker- you shouldn't play with just two players. There was actually only one story where we seemed to have a big difference in estimate: 8 vs 13 points. But as it turns out, our decks just didn't have any numbers in between 8 and 13. We had both wanted to select a 10, but since that wasn't there we just had to pick something slightly higher or lower. Being the planning pessimist that I am, I of course picked the 13. :-)

So there you have it: I played the game of planning poker. It wasn't anything special or extremely different from the ways I've done estimations before. But I guess that contrary to popular belief, being extremely different is not what Scrum is about. What is it about then, you ask? I'll let you know when I find out. Because if I answered that question now, I'd just be repeating the Scrum/Schwaber mantra.

This scrum? Or that scrum? Or that scrum?

This week I took a training that now officially makes me a certified scrum master.

Or wait... let's make it sound even more official: I'm now a Certified ScrumMaster! There, that looks a lot better. And geeky, with a camel-case word in it. But actually all it takes to become a certified scrum master is completing a two day training. Now the training wasn't bad, mind you. But I do feel that a certification should require some kind of exam. Especially a certification that claims you're a master in something.

One of the things that I really noticed during our training is the apparent difference between the way our trainer implements scrum in companies and the way I understood it from Ken Schwaber's books (on agile software development and on agile project management) and video (Google TechTalk on scrum).

I have the feeling that in Ken's approach the role of the Product Owner is much less involved than what we've been taught this week. And that the actual ScrumMaster role is a lot less intensive then what Ken suggests in his TechTalk.

The Product Owner role we've learned during our training was pretty close to what Toyota seems to call the Chief Engineer. And that's a term we can probably all imagine what it means. In my recent history it has been called: technical lead, technical project lead, technical team lead, principal developer and I'm probably still missing a few. The only real difference I see is that the Chief Engineer is empowered, meaning that he/she has the backing of management and is allowed to do the things necessary to get a product or project completed. But of course having a Chief Engineer somewhat dilutes the role of the scrum master whose major responsibility is guarding that the team really follows the process. With such a simple process, that should never be a full time job. Which Ken seems to suggest it often is.

Of course in scrum it doesn't really matter if companies implement it slightly different. After all, this is an agile process. So what's a little flexibility between friends. And I actually believe that this flexibility is what makes scrum work for so many companies. Have a little faith in the ability of your people to somehow work towards the goals that you set out for them. It of course depends on the people, but then again... that's what I already said a few months ago.

What this training mostly showed me is that it really matters a lot who helps you implement scrum in your organization. If Ken Schwaber would have taught us, we probably would come away with a "completely" different interpretation of scrum. Not necessarily better or worse, but definitely different. Now that is something that you might want to consider before you book the first scrum training for your company.