Effective software development

Multi-Release Burnup

In my experience, Agile projects almost never have a single milestone at the end. The business wants to see multiple milestones along the way, taking internal releases from the development team even if they’re not prepared to make them public. The simplest dashboard I know to illustrate this situation is a burnup chart with multiple goal lines, indicating the goals of each milestone.

This sort of chart is trivial to create by hand or with a spreadsheet. The typical Agile Project Management software, while providing a myriad of ways to view data, never seems to include something as simple and powerful as this. Fortunately, it doesn’t take much time to create your own. It takes a few minutes at the end of each sprint to update the chart, and you can make sure that the data is correct as you do so.

Let’s take a look at such a chart after 11 sprints of development.
You can see that the expectations were pretty ambitious at the start for the first two development releases at the 4th and 6th sprints. When actual results didn’t pan out according to plan, the business cut scope for these releases. By the 5th sprint when they planned the third development release for the 9th sprint, their guess about scope was much closer to reality. For the alpha and beta releases, the business started with a safe expectation, and then increased it as results made it look too pessimistic.

You can eyeball an extension of the line of accepted stories to see that the current goals look pretty reasonable. As of sprint 11, it looks good to meet the expectations for the alpha release and almost certain to meet the expectations for the beta release. Nothing is a sure thing, of course. With a simple burnup chart we can monitor progress all the way to the last release, prepared to modify our plan if needed.