Burnup Burndown

Sorin pointed out in his comment on my earlier post that burnup charts make changes to scope explicit, while burndown charts do not.

I’d say, Yes, Sorin is correct. And No. And, I was not explicit in my use of the word scope. So I’ll try to clarify.

Burnup and burndown charts start from a different set of assumptions about change.

John Brewer describes one of the benefits of using a burnup chart with a finish line: …based on that extrapolated curve, you can graphically show managers the impact of scope changes. “See, we were going to finish around here, but because of the new requirements, we’re going to have to do _this_ much more work, so we’re going to finish around _here_.”

And: Tracking the history of the finish line is useful for presentations to top management. “Why is the project late?” “Because you moved

the finish line.”

Burnup charts assume a relatively fixed scope that says “when we finish all these stories, we are ready to release.” The finish line changes when someone (management or the customer, we assume) adds or removes stories from the scope. Developers can also change the finish line when they discover that a story was more complex or difficult and they break it up into additional stories.

I would use burnup charts on a project that was working towards a relatively fixed scope.

But, if I were working on a Scrum project, where the project is managed empirically, I’d use burndown charts.

Scrum assumes that rather than attempt plan deterministically, it’s more effective to obtain frequent feedback both on how the team is making progress and on how the product is shaping up.

The product owner sees working software at the end of every sprint. Once he has his hands on the product, he may see new things to add, or he may realize that the product has significant value as it is.

A Scrum project could have 3 burndown charts, each associated with a different backlog. Each shows the estiamated effort remaining (rather than stories completed).

The burndown for the product backlog shows estimated effort for all the remaining desired times for the product. It’s sort of the grand product wish list. I’d expect to see the product burndown go up and down as the team finishes features and the product owner adds new desired features. This shows how the product is shaping up. Reaching 0 may mean the product is fully mature, there aren’t any new ideas to go into it.

The product owner allocates features from the product backlog into probable releases. The burndown for the release shows how the team is progressing towards meeting the desired release date. If the slope of the line on this chart shows that work is progressing more slowly than anticipated and the product won’t be ready by desired release date, then the product owner and management can make choices that will help to meet the date or they can change the date.

The team has a sprint burndown that shows how they are progressing on the goals for that particular sprint. At the beginning of the sprint, the team bites off a chunk of the top requirements, as much as they believe they can accomplish during one sprint. If they find something is taking longer or is more complex, the effort remaining goes up. If the learn that something is more difficult than expected they add to the effort remaining estimates. That shows up as an up-tick in the burndown. The team uses the sprint burndown to get better at estimating. Within a sprint, there is no external person saying “add requirements to scope.”

So it comes down to different ways of thinking about and managing change within a project. Burndown and burnup can both be useful, and it depends on the context.