Sprint Burndown Chart for Agile Development Tracking

After a release has been defined, iterations have been scheduled, and features to be created during the iteration have been turned into tasks and tests, the real work begins. The team can actually start working through their tasks and building the intended product. Now, new questions arise: "How are we doing?" and "Are we going to make it?" The nature of iterative development require these questions to be asked at two levels: for each iteration and for each release (or the entire project itself if there is only one release).

Measuring Iteration Progress

When considering a team's progress within an iteration, it is important to view a measure that reasonably reflects that progress throughout the iteration. Completed features are one possible measure to use, but the feature completion rate tends to be slanted (sometimes rather heavily) towards the end of an iteration, so it may not be a very good indicator when you're only half way through. Passed acceptance tests provide a less slanted metric, but the effort required to be able to pass a set of tests may vary widely, so it certainly should not be the only metric viewed. Task progress provides a very telling measure of overall iteration progress and has the potential (though it often does not) to remain at a constant rate throughout an iteration. The Burndown Chart shows a trended view of task progress and is the most common measure of iteration progress.

A simple burndown chart is used in Scrum to show a trend of the remaining To Do estimate for all tasks within the sprint (iteration). By adding the completed effort to a burndown chart, the total current estimate within the iteration becomes visible as the total height of the To Do and Done bars. 

Simple Iteration Burndown (with Done included)[/caption] The chart below shows the current iteration burndown as the purple line and the prior iteration's burndown in the blue line. A projection is made (dotted gray line) for the current burndown based on the team's historical progress. 

Measuring Release Progress

While iterations serve as the lifeblood of the development team, releases represent the lifeblood of the business. As a result, a team's ability to successfully deliver software to the business is of critical importance. Given the tremendous churn inside software projects, accurately communication progress, status, and change throughout the development cycle remains a challenge. On the other hand, because agile development uses the incremental delivery of working, tested software features as its primary planning and tracking asset, directly visibility into project status can be very straightforward.

Let's say the original release plan included 100 features that were originally estimated at 250 ideal days (or story point, days, hours, etc.) of work. Since progress of the release is measured in terms of completed features, at any point in time during the release, insight into the amount of work (i.e., number of features and total feature estimate) completed and remaining is simple to calculate and display. Since agile development is measured in a binary fashion - a feature is either complete or not, with little to no credit given for 'partially' complete work - it is a fairly simple process to accurately convey status.

While planning and executing at the iteration level is very important, teams should not lose track of where they are in context of the overall release plan. In their desire to make sure iterations are successfully delivered, some teams may lose sight of their progress against the release goals. Additional scope may continue to creep into the plans as the team marches forward. As a result, each individual iteration appears relatively successful to the team, but the higher level goal of delivering the overall release is sometimes forgotten and changes in the release plan are not communicated to the organization. Consider the graph below, where the team continues to complete features each iteration, but new features are being added to the release just as quickly. If the team does not check its progress relative to the overall release, this situation may not be identified until the release is about over.

In addition to completed and remaining work, other considerations include new features, removed features, and changes in estimates. While agile development thrives on being able to embrace and benefit from change, being able to analyze, understand, and communicate this change remains critical in any situation involving external sponsors and stakeholders.

Previous Article
Collaborative Workspace for Agile Teams
Collaborative Workspace for Agile Teams

Lots of agile teams have made open areas work. There are ways to encourage people to work in such collabora...

Next Article
Code Refactoring in Agile Programming
Code Refactoring in Agile Programming

Code Refactoring is the process of clarifying and simplifying the design of existing code, without changing...