A Few of Our Burn-Down Graphs

More than a month ago, I promised to show you a few burn-down graphs. As you now know, we hibernate during winter in the arctic areas, but now it’s spring (!), so I’ll get going.

I’ll be showing burn-down graphs for a project we started to create a spanking new product. We started November ’08. As always we’re focusing our efforts on sustaining a lean and healthy process throughout.

Let me show you, through the perspective of a burn-down chart, how we’re trying to achieve this.

First iteration (sprint)

sprint1

(Very short recap: Horizontal axis represents days into the iteration, vertical is hours of work left to do. Blue line is ideal burn-down, and yellow line is actual burn-down, or completion of our estimated tasks). From the graph, you can clearly see that we did not add as many tasks as there were available hours in the first sprint. Being the first iteration of the project, we figured a lot of unforeseen challenges will be discovered along the way. This assumption turned out right. You see the yellow line rising, or flatting out as we add new tasks with their estimates. The big drop at the end is due to a couple of large tasks (probably not sufficiently broken down into smaller ones) being completed. If I remember correctly, we also figured out couple of tasks we could do without. Deleting unnecessary requirements (or stopping them before they ever hit the backlogs) is just about the most effective way of gaining headway, which really shows up here.

Second iteration

sprint2

As you can see from the second iteration’s goal, we’re aiming for release maturity early. But be ware: “Mature for release in functionality richness” does not mean that we’ve overloaded the product with features already, it just means we’ve started implementing the most most important ones first (usually about 20%). Starting like this is important to sustain a lean process — get your project released with most important features quickly in order to start getting real feedback from real users on your most business critical functionality. It’s all about getting eyes and ears, to confirm that we’re moving in the right direction at all times. You can’t fixate direction during planning, you have to keep your eyes open to navigate along the way.

You can also observe that we left quite a bit of room for unplanned tasks in this second iteration as well. In retrospect, this also seemed like a wise decision. The horrible “flatness” of the end of the graph was the holidays around Christmas! Nobody was working. But as you can see, we came back with a bang at the end. A little vacation always do you good.

Third iteration

sprint3

In the third iteration, we leave less room for unplanned tasks (yellow line closer to blue line) we’re narrowing scope and focusing on getting to done on all open threads. We should aim for Done in every iteration (meaning that we’ll tag and release a new stable version on every iteration) to keep things tight, but in the first two iterations we weren’t able. Even though you might think there is a great deal of deviation between real (yellow) and ideal (blue) burn-down, don’t forget that this is based on estimates alone. I’d say we made some OK estimates during this sprint (either that, or we’re great at faking the progress according to our estimates).

Fourth (and current) iteration

sprint4

Let me just point out first that there are a couple of problems with this iteration’s goal. “Test everything” is not what you’d normally should put in a goal as it is implicitly required for all iterations in any project. But as it turns out we’ve just recently started unit-testing JavaScript code — and thus we had built up a backlog of untested JS-code in this project. Backlogs are a real enemy, so we’re going at it fiercly in this sprint.

Same goes for “no loose ends“. Be careful not to over-commit during sprint planning. All requirements committed to should be brought to 100% completion. 90% done at demo-time is the worst state to be in — you are not allowed to demo it, and you’ll have to carry it’s weight into the next sprint, or delete it to cover it’s tracks in the code that is going to be released. Always aim for 0% (push it back to requirements / product backlog) or 100% (get to done, at all costs).

During the current sprint, we did just make such a decision. We saw that we were stretched too thin over too many requirements in one sprint, making sprint progress slow. And thus, we pushed a big item back into requirements. Instead we are adding figuring out and adding quality-leveraging tasks for the requirements already committed to in this iteration. We’re hoping this will bring us to 100% during this sprint on 3 requirements, instead of 90% on 4.

We’re ending the current sprint next Wednesday (4th of March ’09), which is demo-day. I’ll return with more information from this ongoing project during the next iteration.