Burn Up Charts: How to Know When the Work Is Done
Many Agile practices include burn up and burn down charts as new ways of forecasting and communicating when work will be complete. If you have been part of a Scrum team, you are probably already familiar with the burn down charts that are often used to visualize progress in each Sprint. While they are a good tool for helping teams understand their progress and adjust to daily plans as needed, they do not always provide value beyond the horizon of a single Sprint (anywhere from 1 - 4 weeks). Leaders often need longer range forecasts to support decision making and align efforts in disparate departments such as marketing and sales.
Agile practices break large chunks of work into small slices and each one provides value to the user. Those small slices of working software are used to make forecasts. Each slice (typically a User Story), are the data points that show up on burn down charts. As the Agile Manifesto goes, "Working software is the primary measure of progress." It is the basis for teams planning work for each Sprint based on what they have accomplished in the past. However, there are other ways you can use those slices to make longer-range forecasts.
The simplest way to forecast how long it will take to get something done is to look historically at how much work the team was able to do in a fixed period. For example, if your team was able to complete 15 items over the past three weeks, you can safely forecast that the next 30 items in their backlog can be completed in the upcoming six weeks. Keep in mind that this assumes the size of the next 30 items are an average similar size of the past 15. This can be overcome by assigning a relative weighting, or points, to each item and using that instead of counting. It also requires that new work is not added anywhere within the next 30 items.
A more visual way of longer-range forecasting is with burn up charts. Burn up charts utilize historical data that reflects how much work a team has completed to forecast a timeline for a scope of work. They can be used to forecast any scope of work the team may have in their backlog. Burn up charts learn and adjust overtime by using multiple data points to plot a projection. The farther along you are, the more data available, and the better the forecast. It is similar to how a mapping app on your phone estimates when you'll arrive at your destination. Using a linear projection of the all of the previous data points will give you a better forecast for when the work will be done than older methods that were based on speculation of how many hours or days tasks would take to complete. You can also provide a range of probabilities by drawing optimistic and pessimistic projections based on evidence from periods of higher and lower levels of productivity.
The example burn up chart above has bars that show the points that the team completed for each of 3 iterations. The dashed grey line is the trend line of work that has been completed in the past. This reflects that this scope of work will complete where it intersects the scope line, sometime after July 7. The dotted green line shows a more optimistic projection using the higher number of points completed in the May 5 iteration, while the dotted red line shows a more pessimistic outlook based on the fewer points completed in the March 24 iteration. Through this range of possibilities, you can be fairly certain the work will be completed sometime between early July or mid-August. The orange line reflects how the scope for this effort has changed over time. In this case, the product management made a decision to cut some of the scope so value could be delivered to customers approximately a month earlier. Many Agile work management tools can generate a burn up chart for a specific scope of work or they can easily be created in a spreadsheet.
Burn down charts do not have to be based off points completed. You can choose to look at a chart of points, items, or some other metric completed over time which is most consistent and predictive for your team. With many teams, using relative points is a better predictor than other metrics and requires far less time for estimation than using absolute units of time.
While you may be tempted to pre-plan when slices of work will be completed for weeks or months in the future, be aware that this could require more work to rebuild the plan whenever a change is necessary. Requiring more work to adapt often results in more resistance from your team and runs against the Agile value of "responding to change." Instead of pre-planning, make sure your backlog of work is sequenced in the optimal order and use one of the above methods to get a forecast for the current conditions. Ultimately, it makes use of the most current data and will save you work!
