menu
Last updated on
Plutora Blog - Agile Release Management, DevOps, Software Development

Using a Burndown Chart for Effective Project Forecasting

Reading time 14 minutes

Agile can come with a lot of confusing words and concepts. We sometimes find ourselves surrounded by odd-sounding words like story points, velocity, WIP, Kanban, and burndown.

It can feel bemusing. It’s easy to get frustrated with all of the seeming “rules” of agile, especially when we’ve got real problems like looming deadlines and difficult stakeholders. It can sometimes feel like all these rules get in the way of just getting the work done. But it doesn’t have to be that confusing or frustrating.

Today I’m going to show you how you can use the burndown chart to help manage software projects and deliver quality work on time—and all without pulling out your hair!

Exactly how will we do it? Firstly, I’d like to take you through a real-world scenario, using no jargon, to explain the concepts of the burndown chart in plain English. After that, we’ll take a deeper dive into the burndown chart.

If you’re interested in demystifying burndowns, let’s get to it.

Burndown Charts in Real Life

As promised, I’ll introduce you to the concept of a burndown without using any technical jargon. Often as an industry, we drastically overcomplicate ideas. In fact, we often intuitively use these ideas in our daily lives without noticing the complexity. Hopefully this short story will give you a stronger grasp of what a burndown is and why you’d need it.

I hope you’re sitting comfortably—because we’re about to begin!

It’s an evening after work, and you’re out meeting a long-time best friend from school, Tom. As you get to chatting, it’s just like old times, and before long Tom lets you know he’s getting married in the summer. “Do you still make those amazing cakes?” he asks, recalling how you were the school’s birthday cake connoisseur.

“Of course!” you reply.

“Well, I know it’s a little cheeky, but would you mind making some of your cakes for my wedding? That would mean the world to me,” he says. Naturally, since he’s such a good old friend to you, you oblige.

As always, the months and days pass quickly, and the wedding date starts creeping ever closer. But just as the grass starts growing as spring arrives, so does the size of your favor for Tom. Since Tom was always a popular guy, his guest list has spiraled completely out of control. Accordingly, the original amount of cakes you’d agreed to make rose from 50 to 100 to 200 cakes!

Yikes.

With a few days before Tom’s wedding, your nerves are really kicking in. You’re out with another friend, Sarah (who, not so coincidentally, works in a Scrum team) when you confide in her that you’re starting to feel nervous.

“The real problem,” you explain, “is that the way the cakes are made has to be fresh, which means I have to make them all the day before. But that’s 200 cakes in around 10 hours. Sarah, I’ve never made that many cakes before!”

“Hmm,” Sarah says, gazing off into the distance. A wry smile emerges from the crack of her mouth. “I think I have a plan for you! It’s something I do at work all the time.” She goes on to explain, “We often have things to do that are uncertain. I mean, it’s software, so sometimes we really don’t know how long things will take. But we have this thing we use to help us, and we call it a burndown chart.”

“A what?” you ask, confused.

“Let me explain,” she says. “How it works is simple. First, you need to know the total amount of work that you’ve got to do, so for you, that’s 200 individual cakes, right? Second, you need to know how long you’ve got—in your case, that’s 10 hours. So that means in order to deliver 200 cakes in 10 hours, you need to be on track with making 20 cakes an hour.”

She continues, “The best way to manage your work is to stop periodically—we call these ‘sprints’—and inspect how things are going. If, for instance, you’re ahead of schedule, you’re golden, and you can keep on baking the same way. But if you find that you’re starting to slip behind, you can start to tackle your complexity.”

“In fact, the best way to show the concept is on a chart. It works like this: you plot the x-axis as the things you need to get done—we call these ‘story points.’ On the y-axis, put the number of things you want to get done. Then, all you have to do is draw a straight line from ‘200 to go’ right down to ‘0 to go.’ Here, let me show you.”

Sarah flips over a napkin and draws out a sketch of the diagram:

Image result for burndown chart hand drawn

“Do you see? Now, you’ve got a line that shows exactly where you need to be at each step of the way.”

“But what if I’m not where I need to be at?” you ask.

“Well, 200 cakes is non-negotiable, right?” Sarah asks. You nod your head in agreement.

“But exactly how the cakes look is negotiable, right?” she confirms. Again, you nod.

“Okay—so what that means is, if you find that you’re spending too much time on the first cakes, you can start to simplify the ones you make after. I’m no baker, but that could mean you cook bigger batches of smaller cakes. Or, you could spend less time icing them.”

“And that’s the thing!” Sarah continues excitedly. “It’s all about you having the information you need to make decisions. When you’re in control, it makes life easier and much less stressful.”

“The best part is, it’s nearly impossible to miss the deadline—trust me. If you start to get off track, keep simplifying! People at work always say they can’t possibly live without X, Y, or Z. But I’ll let you in on a secret: we nearly always find some extra work that’s not needed! It happens all the time.”

The Burndown Chart

So there you have it. Sarah took us through the basics of a burndown chart and how we can use it to gain control over our project. At Plutora, we believe in having control and visibility into our work. And as you can see, burndown charts are all about mapping out the work to be done and pausing periodically to review how far you’ve come and how far you’ve got to go. That’s really the essence of Agile: take a small step, review, course correct if needed, and continue.

I imagine that by now you’re thinking, “Okay, I get what you’re saying. But what about those other things you mentioned? What about story points and sprints? Where do they come in?”

And these are important topics to cover, so let’s cover them now.

Anatomy of a Burndown: Scrum and Story Points

There are many different parts of the burndown puzzle. In a moment, I’ll take you through setting up and running your first sprint managed with a burndown chart. But first, let’s talk about those other important terms.

Scrum

Scrum is an agile framework. True Agile development is really any way of organizing your work that adheres with the Agile Manifesto. But the Agile Manifesto is fairly brief and doesn’t really give that much detail. Scrum is a framework that builds on top of the ideas put forward in the Agile Manifesto and makes it a bit more real and tangible. At its essence, a Scrum team is a small, cross-functional (meaning it has all the necessary skills) team that operates in small bursts of work called sprints. Scrum teams have specified meetings, roles, and standardized ways of performing work.

Story Points

Story points (sometimes called complexity points) are arbitrary weightings assigned to individual pieces of work to note their effort or complexity to complete. Rather than the points having value themselves, their value lies in their size relative to other pieces of work. Story points can come in many forms: linear numbers (1, 2, 3, 4, 5 …), Fibonacci sequence numbers (1, 2, 3, 5, 8, 13 …), or even abstract concepts like T-shirt or animal sizes (extra-large, large, medium …).

By now you’re probably thinking, “That sounds interesting, but what’s the point of story points?”

In short, humans are bad at estimating time. Story points are a way of abstracting out the concreteness of time. But don’t worry—that doesn’t mean we’re paying for our groceries with Monopoly money, so to speak! We use story points to look at what we’ve achieved to then understand what we can achieve in the future.

Points work like this: rather than asking a developer, “How long will X take?” you can ask, “Is A work roughly as complex as B?” If the answer is yes, you can assume that the work will take roughly the same amount of time as the work from before. By working like this, you can avoid many different biases, such as positivity bias or anchoring bias.

Getting Started With Your First Burndown Chart

Hopefully, by now you’re itching to see how this whole burndown thing works in practice. So what we’ll cover next is how to take these ideas and put them into practice step by step.

Burndown Chart
Breaking the project down into sprints, tasks, and points.

1. Agree on a Sprint Length

For your upcoming work, how long do you want to work before you stop and assess your progress? Typical sprint lengths vary and can go from as little as one week to several weeks. It doesn’t matter too much how long it is—that’s up to you.

2. Break Work Into Chunks

As a team, break down the work you’ve got to do into simple, easy-to-complete chunks. Breaking things down into small tasks gives you a fine-grained view of your process so you can see your progress on your burndown. If your tasks are one week long, it’s going to be one whole week before you can inspect your process and adapt—not good!

3. Estimate With Points

Now, with the work broken down, you’ll want to assign points. Go through each story and assign points based on how complex you think the work will be. In fact, the act of voting is enough to unearth tricky questions and assumptions. If you want, you can take this up a level with a game of Planning Poker.

Now You Can See Into the Future

By now you might be thinking about how I promised you I’d show you how burndown charts would help with project forecasting.

You’re right—I did. But all the groundwork we’ve done has brought us to this very point. We can finally discuss how burndowns and story points all help us to perform project forecasting.

Let me explain!

Now you’ve got a sprint’s worth of work with assigned story points. For your first sprint, you’ll have no real clue how many points you’ll complete. However, for the next sprint, you’ll know roughly how many you did last time, and you can use this as a guide. After about three sprints, most teams start to stabilize the amount of points they estimate for a given sprint, which is called velocity.

And this is where the magic happens!

Now that you know your velocity, you can estimate how long future work is going to take. All you have to do is follow this formula:

How long your work will take = Planned work (in story points) / Current velocity * Sprint length.

So if you have 100 points’ worth of work, and you complete roughly 20 points per two-week-long sprint, you know that 100 points of work will require roughly 10 weeks to complete. And as with our story about Tom and Sarah, you can use these estimations to simplify your complexity. And if you want the work completed sooner? Simplify it.

Burndown Chart

“Gotchas” to Watch Out For!

Before I part for today and you run away eagerly to implement story points and burndowns in your team, I did want to leave you with a few words of warning. Sometimes in understanding how something works, it’s good to look at how not to do it, the gotchas! Below are the two main ways I’ve seen teams trip up when implementing story points and burndown charts.

Gotcha One: Story Points Do Not Equate to Time

A very common obstacle when dealing with burndown charts is wrapping your head around the fact that story points are not time. We are so hardwired to use points for estimation that it feels very natural, and left to our own devices we revert to this natural behavior. But, we are deliberately avoiding the notion of time because of how bad we are at predicting how long work will take.

It’s very common to see a team member saying something similar to: “For our team, one point means 1 day”. But what’s wrong with that? I can almost hear you asking. It is a very logically straightforward statement, I’d agree. But let me explain why it can be damaging to your forecasting efforts.

Story points are deliberately abstract. We sum up the total amount of points completed in a given sprint to work out what we can commit to in the future. If we use time, we’re relying on our ability to guess how long the work will take based on current knowledge. When we use points, we are leveraging historical, empirical data to ensure precision.

Gotcha Two: Beware Reporting on Story Points

As with the previous gotcha, we trip ourselves mostly when we apply current thinking to our new scrum processes. And one area that’s’ very common for a lot of companies is reporting.

The idea of seeing a chart of our velocity (our total points per sprint) can be tempting. It can be especially tempting when we’re talking about an abstract concept with business stakeholders.

But, again, what’s the big deal? You ask.

And the big deal is: points inflation. Our velocity is called velocity for a reason: it fluctuates wildly. When we start reporting on points to business stakeholders, a mysterious (or not so mysterious!) phenomenon appears: points always trend upwards! When we reward teams for “completing more points” they consciously or not, start to inflate estimates to reap the reward.

Not only is point inflation dishonest, but it erodes the confidence of the business in a team. If the team is reporting lots of points complete, but the business sees little output it can cause unnecessary tension. Instead, we should keep points as a tool for the team to understand their progress, and instead report on outcome, not output metrics, such as user satisfaction scores.

Burn, Baby, Burn!

Hopefully that gives you a good understanding of what a burndown is and how it can be used for project forecasting. Burndowns aren’t only good for forecasting; they can also be great for team morale. When your team sees how work is progressing, they’ll get excited and motivated to burn more and more work. Creating a burndown is all about giving your team tools to review their progress and adjust their course if needed. This is the essence of agile software.

So go forth, use story points, plot your sprints on a burndown, and empower your teams using your prescient skills of seeing into the future!

Lou Bichard Lou Bichard

Lou is a JavaScript full stack engineer with a passion for culture, approach, and delivery. He believes the best products emerge from high performing teams and practices. Lou is a fan and advocate of old-school lean and systems thinking, XP, continuous delivery, and DevOps.