There's a lot to like about burn-up charts. They're compact, but very information rich. They convey several key concepts visually and in a way that's easy to understand. They make it highly intuitive to understand the likely end date, and the uncertainty around that likely date.
So why am I picking on them? Because (like many things, especially metrics) they can be used badly or in the wrong mindset, and in my experience often are. Wrongly approached, burn-up charts can be reflective of some problematic thinking that can keep your team from being successful.
I don't think these problems are the result of bad intention. Rather, I think they stem from not thinking about how "what the burn-up chart shows" relates to "how we expect a typical Agile project to run." My goal is to point out some of these "impedance mismatches," and present some ideas on how to make sure you and your burn-up chart are on the same page.
What's a burn-up chart, anyways?
Simply put, a burn-up chart is a plot over time of work completed, and a plot over time of the "target" amount of work we need to complete to achieve a goal. By looking at the level and slope of the "completed" line, we can understand when we expect it to intercept the "goal."
The concept of a burn-up chart can be applied to a wide variety of situations where "work" is achieved towards a "goal." Burn-up charts can be be done with many kinds of "work achieved" (story points completed? stories completed? defects closed? tasks complete?), can be plotted on multiple timescales (daily? hourly? monthly?), and can be used for a variety of goals (stories burning up for a single iteration? tasks burning up to complete a given story? stories burning up for a release?)
For purposes of this article, however, I'm going to restrict myself to the most frequently used type of burn-up chart, which is a "release burn-up." The "unit of time" for this chart is is generally sprints/iterations, and the "unit of work" is generally measured in story points (or whatever the team's estimation unit of choice may be). The "goal" line represents the total estimated work that's "in scope" for the current release. The "burn up" line represents the number of story points that are completed each iteration. It looks something like this:
To make it more useful, we can add a "trend line" for the work completed, which allows us to visualize where the intercept will happen:
Because our velocity isn't completely smooth, we can also extrapolate "worst case" and "best case" velocity estimates, to show us the range of uncertainty around our possible dates:
And there we have it. It's fairly simple to draw. And it answers a whole host of potential questions around "how is the team doing" at once. You can see at a glance the "when do we expect to finish?" The "range of uncertainty" is reasonably easy to understand. You can clearly see whether the team's velocity is relatively steady or jumping around.
You can also answer a number of what-if questions easily - how much would we need to cut if we need to be ready for production by date X? Draw a vertical line on the date, and you can read from the projected trend lines the best/middle/worst case estimates on how much we can get done, so we know how big the cuts are. Will be ready by date Y? Is it in the range of uncertainty? If not, probably not without making changes. If it is, we can see whether it's an aggressive or conservative target.
So, yeah, it's a pretty good chart. It's so commonly used that most Agile tracking tools will build it a burn-up chart for you. Here's a few examples:
So, enough about what's good about burn-ups. This post is supposed to be about what can go wrong with them, so let's get into that.
Burn-ups can block discovery
Let's say we're in the early stages of a project. We did a quick discovery exercise, and found 200 points worth of user stories. We did a velocity projection and estimated the team could do about 20 points of work per iteration. Our first two iterations roughly bore that prediction out. Our burn-up chart looks something like this:
Great. It looks like we'll be done around iteration 10.
Fast forward to iteration 9. We should be in the home stretch. But we're not - if we look at the actual backlog, we see that there are still 3 more iterations of work! What happened? Let's look at the burn-up chart again:
Ah. The scope moved over time, as new stories were added to the project. This means we have more work, and so we need more time to finish.
The two words most project managers (especially "traditional" project managers) are probably thinking about right now are "scope creep." Clearly, the team should have "held the line" on new scope - if we wanted to add something new, we should have taken something out. This project was "mismanaged."
And, in my opinion, if that's what they think, they're probably wrong. What I described in the last paragraph is completely non-Agile thinking.
The notion that all the work "ought to be known" at the start of a project comes from "traditional" waterfall thinking, where we have an extensive "planning" phase up front that's supposed to uncover every requirement and task in the project before we get started. Deviations from that plan are expected to be infrequent, and must be managed via a strong "change control" process to keep from materially impacting the schedule unnecessarily.
In Agile projects, we do away with the long, drawn-out planning phase that's expected to find everything we're going to need to do. And in doing so, we need to do away with the assumption that all the work we need to do to accomplish the goal is known before we start.
While we might do a discovery phase up front, we should EXPECT that phase is imperfect and will miss a few things that need to be done. Because we're collaborating with customers, we should EXPECT some amount of re-work or re-imagining of features will happen over the course of the project. Those changes aren't "scope creep" - they're the norm of an Agile project.
Expecting that the team should "hold the line" on the scope we knew about at the start of the project, and that any "discovered" stories (either from customer collaboration or new discovery) means we need to remove something else to make room for it, is following a plan over responding to change.
So, what's the solution?
The simplest thing you can do to address this issue is start with the assumption that your scope line will be UPWARD SLOPING, not flat. We don't know exactly which stories we'll uncover, but we KNOW we'll find some. Assuming our scope line will be flat unless "something unexpected happens" sets the wrong expectations, both for the team and the customer.
The exact slope of the line will vary depending on the project, and factors like how unknown the problem space is, how expert the team is in the domain, how many different stakeholders we're trying to satisfy, etc. I find a good rule of thumb to be that a "typical" team will spend about 20% of it's time working on "newly discovered stuff," leaving 80% for the "known at the start" work. So my sample team with a velocity of 20 should expect to discover about 4 points of stories per iteration.
Some people may be howling that allowing this discovery factor is an open invitation to scope creep. I don't think it is. Just assuming the line to be upward sloping isn't the same as saying we'll stop thinking about newly discovered stories and just accept everything into the project. Regardless of how we build the metrics, we need to have regular conversations with our product owner and only accept changes we genuinely want to deliver.
Also, assuming a "discovery rate" can make this a somewhat scientific process. Assigning a "budget" for discovery helps us have productive conversations early in the project. We tell our product owner their "budget" for story discovery is 4 points per iteration. We then track it - in iteration 1, we added 6 points. In iteration 2, we added 3 points, in iteration 4, we added 2 points. Great - we're on track. Or, if we're going into iteration 4 and we've been adding 8 points an iteration, not 4, we have to have a conversation. Was our "discovery" expectation too conservative, and we need to change it (and so change our expected end date)? Or is it that we had a major correction early in the project, and we don't expect it to recur? The point here is that by tracking our discovery against a planned "budget," we can validate our assumptions. We can even do it right in the burn-up chart:
In this example, the green line is how we expect scope to grow over time with discovery, so we should expect to be finished in Iteration 12 (and not Iteration 10, where we'd have projected to finish if we "held the line"). We can see from the trend in the Current Scope line that we're upward sloping, but roughly sticking to our discovery "budget."
One problem with this approach is that (to my knowledge) there aren't any automated tools that make it easy to account for an "expected discovery rate" - the burn-up targets tend to be horizontal lines (if anyone knows of a tool that DOES make this easy, would love to hear about it in the comments). So if you want to track this, you may need to "roll your own" chart to do so.
Burn-ups can cause complacence
Having talked about burn-up charts leading to thinking that potentially caused us to exclude things we ought to do, I want to talk about the opposite problem - burn-ups causing us to do work we don't need to do.
Again, by design, the initial "discovery" for Agile projects trades complete accuracy for speed - we're willing to tolerate some false positives/negatives in exchange for being able to get started writing useful code faster. This means we'll miss some things, but it also means we'll potentially pick up some stuff we think is high value at the time that we'll later learn isn't actually necessary.
Most teams are pretty good at reviewing stories we recently discovered and vetting them for "is this really part of the project?" But teams can be less careful about reviewing the things that are already "on the plan" and "in scope" for the project.
The burn-up chart can contribute to this lack of introspection. If we had 100 points of work at the start of the project, and we're projecting to finish all 100 points within the expected timeframe people are asking for, then we'll just keep churning through those 100 points. They're part of the "baseline" (which on a burn-up chart is literally a line). The fact that we have a scope line with a fixed value as the "target" mentally causes us to treat that amount of work differently from "new" work, because we've already baked it into our metrics.
A good team should (and will) regularly review and "prune" the backlog - just as we expect to discover new work over time, we also expect that we will discover existing work isn't necessary. We should remove those items, even if our burn-up chart "looks good" to getting the work done.
Some of you may be noticing that in the previous section, I argued the scope should be expected to grow over time as we learn things, and here I'm arguing some of the initial scope should be expected to be removed over time. Can't we just assume these effects "cancel out" and go back to the "flat" projected scope line?
While the two effects do partially cancel each other out, the magnitudes aren't necessarily the same. In my experience, the "20% growth" assumption is what I've seen as the "net" effect - we discover new work faster than we remove work.
Again, the goal is to be deliberate about scope changes. The team should be diligent on removing unneeded items, just as they should be diligent about only accepting necessary change. There's nothing "special" about the work that was "in the baseline" - unnecessary work is unnecessary, whether it's "already in the metrics" or not.
Burn-ups can encourage infrequent delivery
There are times when the right way to do a project is to spend several months building a cohesive product, and then release it together. Sometimes you're building a brand new application that doesn't deliver value until it can support certain likely usage scenarios end-to-end. Sometimes we're doing a major restructuring of a module that needs to change all at once. Sometimes external circumstances around how we deliver necessitate a single large release (e.g. something that needs to deploy in parallel with a third party's application that we integrate with).
But these situations do NOT apply to all projects. On many projects (probably MOST projects) we don't need to "build up" 6-12 months of work to have something of value to release to the marketplace. And if we don't need to wait to do a big release, we probably shouldn't - one of the key goals of Agile is to deliver value to production rapidly, and begin to capture that value quickly.
Having valuable code that could be making us money "waiting" on a release is throwing money away. We could be getting value from it, but we're not, because it's "part of the release" that happens six months from now.
The continuous delivery movement has a lot to say on techniques/processes around the "how" of getting code to production quickly. But I'm talking about metrics today, so I won't go into those.
The reason I'm seeing a potential problem with burn-up charts is that, once you're familiar with burn-up charts and grow to like them, you may start structuring your projects in ways that product a good burn-up chart, rather than alternate structures that don't work well with burn-ups but may deliver value more quickly.
The key insights you can get from a burn-up chart is a projection of when a given scope of work is likely to be complete in the (relatively distant) future. If your burn-up chart tracks points once per iteration, they're close to worthless for giving us meaningful insight on how long it will take to complete a scope of work that's only an iteration-or-two worth of effort.
You can address some of this by plotting points more frequently (you might plot your "work complete" in days rather than iterations). But in some cases, that's fitting the data to make the chart work, as opposed to thinking the chart is a metric that gives us useful insight that we can make actionable decisions on. The real question is whether thinking of our project as relatively slowly "burning up" to a large goal is the right way to think about our project at all.
I see this thinking trap frequently on "new to Agile" teams. They are coming from a world where a nine month project is considered "short" and the executive team is used to looking at a Gantt chart. When they switch to Agile, they have slightly shorter projects (say, four months), but they don't have a Gantt chart anymore. But we can show the execs a burn-up chart, and explain it to them, and we can make them relatively satisfied that they still have good insight into how the project is going. But then the burn-up becomes a self-fulfilling obligation - we need to have burn-up charts because management expects burn-up charts. And, subtly, we become mired in our thinking that the "right way" to think about projects is by burning up over time to a goal.
So, what do we do about this? The first thing is to consider whether, like any other metric, a burn-up chart is actually appropriate to your project. What is it going to tell you? Does it fit the way we we're structuring the project to deliver value? Let's be OK having the conversation that a burn-up chart isn't appropriate to our project.
One of the most productive teams I was ever a part of didn't bother with burn-up charts. We'd simply agree "once these 4 stories are done, we can go to production with them," and make that happen - we'd deploy every week or two.
Burn-ups can cause missed expectations
Burn-up charts are great at predicting the "development complete" date for a given project. Ideally, that's also the date we could "go live" with the new project - just click the button at the end of the last iteration and go.
In the real world, this is rarely the case. First (as discussed in the last section), if you're a project that has a significant burn-up chart, you probably aren't sufficiently comfortable with your deployment process that you could just "push the button and go."
There may be a genuine need for other processes to happen that need to take place between the "we're done writing code" and "we're able to go to production." Maybe your application requires regulatory review and approval. Maybe your process is to have a beta testing phase for final feedback before you flip the switch in production. Maybe you need to coordinate the launch of the product with a marketing campaign. Maybe you need to bring a swarm of tech writers in to put together the final "user manual" after the app is done. Maybe you have a major outage that has to happen for the move to production to do a data migration into the new system.
Some of these activities might be able to be done "as you go" during your development iterations, but probably not all of them. Which means there are likely activities that take place AFTER your development is complete, but BEFORE you're in production (and delivering actual business value).
By design, a burn-up chart doesn't show these things. What it shows is how we're progressing towards the "goal," where the goal is generally "we have completed all the stories."
The way we get an expectation miss is if we're reporting our burn-up charts out to a wider audience, and they're taking back the message of "the development and testing for features will be complete at the end of iteration 9 on Aug 1st," and conflating that with "we will be in production Aug 1st." If that's not the case, you need to be careful about the messaging around your burn-up. Which probably means "don't communicate ONLY the burn-up chart."
Some teams "account for" this by putting in placeholder stories and assigning them to "iterations" near the end of the project, so this non-development work will show in the burn-up. I think this is often problematic, and is twisting the process to fit the chart. Assigning "points" to "do the marketing for the release" is implicitly claiming the marketing activities are measurable on the same scale as the development work, and will have the same velocity. But if the development team moves faster than we expect, the marketing doesn't magically take less time, and we'd be in trouble if our chart assumed we would.
While I'm not a fan of them for many purposes around tracking software delivery, the much maligned Gantt chart can actually be your friend here - tracking dependencies and "cascading" dates appropriately is exactly what a Gantt chart is good at. If you're putting together a "showcase" for your metrics, a slide with a name like "From Development Complete to In Production" showing the dependencies and timeline starting with your current best "development complete" date and ending with the date you're live in production can help everyone understand what those activities are, how long they'll take, and when the project is actually going to be done.
As I said at the beginning, I generally like burn-up charts. They're incredibly useful tools, and for certain kinds of projects are an ideal way to communicate progress succintly.
That said, I hope I've at least raised your awareness that (like all tools) burn-ups aren't perfect. If we think about them the wrong way we can drive undesirable behavior, set incorrect expectations, or miss opportunities.