A Better Burndown Chart For More Accurate Sprint Planning

The Scrum method of Agile development is excellent. I have used it with my teams for more than 5 years now, and we deploy successful sprint after successful sprint, each and every month. One of the secrets of that success is that I have varied from the traditional burndown chart and sprint estimation suggestions that are taught when a person learns about Scrum. Fortunately, the original Scrum books state that Scrum is not "prescriptive" - meaning that it is not a hard and fast set of rules that are set in stone. We are suppose to modify and adapt it to work in our organization. If you have had issues with making accurate burndown charts that reliably tell you when your sprint will finish, then perhaps my suggestions can help.

The traditional definition of a Scrum team is that of a self-managed team that does not have set roles. The team is supposed to decide who will perform each task. That is a great concept, except that some people have developed careers as software developers and some are experienced at testing. Tasks may vary in the amount of development and testing required, and testing typically can't start until the development is complete.

Another issue with traditional Scrum is that teams are encouraged to estimate tasks using "Story Points" instead of hours. Story Points are an arbitrary unit of measure that a team can use to try to figure out its "velocity" - the amount of work that it can do in a sprint. What I have found in working real-world projects for business customers, is that the customers just want to know if their tasks will be completed by a certain date. For the sake of clarity in communicating with my Product Owners and Stakeholders, I use hours for estimates so we don't get all tangled up trying to explain and understand a new unit of measure. Yes, it is difficult for a team to make accurate estimates at first, so you might have to account for that as a ScrumMaster, but the longer that a team works together on the same application and with the same team members and Product Owners, the more and more accurate they become. It just takes practice.

Let's take an overly simplified example. Suppose I wanted to conduct a sprint that added two new features to a Web application that my team develops for a customer.  The developers and testers give the ScrumMaster this estimate which is expressed in hours:

	Dev	Test
Feature 1	4	2
Feature 2	3	9

Traditional scrum just adds up all of those numbers and says that this sprint represents 18 hours of work. If I have 1 developer and 1 tester assigned to the team, and each person can reasonably expected to complete 6 hours of productive work per day*, then they could complete 18 hours of work in 1.5 days 

	Total Available Hours
Day 1	12
Day 2	6

The resulting burndown chart would look like this:

If you communicate to your customer that you will finish your sprint in 2 days, then later you will find yourself trying to explain why you are late. The problem comes back to assignment of tasks and dependencies.  In the sample sprint, the developer has 7 hours of work, and the tester has 11. For the sake of this example, we will assume that all of the test hours are for actual testing, not for developing test cases or automation, so the tester cannot begin testing an item until it is developed. We will also assume that the item is immediately available to test as soon as it is completed - the are no delays for build or deployment. 

Since the traditional model doesn't consider dependencies, the ScrumMaster is in trouble from the first day. In our example, testing cannot begin until the developer has burned down 4 hours and completed Feature 1. Unless you are going to make the tester work the night shift, she can't burndown 6 hours the first day. She might be able to burn down 2 hours on that first day, after the Feature 1 is ready to test. Then the developer moves on to Feature 2 and completes it in 3 hours. Meanwhile, the tester completed testing Feature 1 in 2 hours, so she is once again waiting for development to complete, and she is unable to burndown work for an hour. At last, Feature 2 is ready to test and the tester can complete the work, but because of delays while waiting for features to be developed, the testing rolls into a third day.  The corrected burndown that breaks development and test out into their own lines, looks like this:

I can hear you asking, "Is that it? One day? You are making a fuss because of one day?" Yes. Yes, I am. In a tiny, tiny project like this, the schedule went from 2 days to 3. Adding a 1 day to a 2 day schedule represents a 50% error! Imagine, then, how far off you might be if you have a big sprint with lots of tasks and people. You might also observe that this burndown reveals something else about your project that a traditional burndown chart will not: it shows that we need more testing than development. If I have the two kinds of resources lumped together, then I can't tell if I have enough of the right kind of resource.  

This corrected burndown still doesn't represent real-world projects. I don't know about your projects, but mine have bugs and those bugs have to fixed and regressed. Then, when it is all ready, we have to deploy to a staging environment so our customers can perform User Acceptance Testing. They may find more bugs that need to be fixed, and then we deploy to production. The really, really corrected version of the burndown looks like this:

"What?! We only had 7 hours of development and it took 7 days??" is what you will hear from your customers if you told them that you would be done in 2 days. This last chart includes a weekend, bug fixing time, deployment time (to Stage and Production), and a day for User Acceptance Testing (UAT). Reliably, the team will be burning down the last hours on the 12th, so on the 13th we have zero hours remaining. I call the work at the end "Sprint Overhead" because it represents tasks that must be completed for a production launch of a Web application, regardless of what features we develop. The length of the bug fixing and UAT periods may vary according to the length or complexity of the sprint, but there is always some overhead. 

So let's look at a better example. You can download the spreadsheet that I used in these examples and use it on your projects, but if you make a commercial software tool that uses my burndown, then I expect a fair royalty. Anyway, suppose we had a bigger sprint with more items, and the estimates (on the "SprintItems" Tab) might look like this:

When I fill out the "Staff" tab I ask the team who is going to work each of the tasks, and then fill in hours under that person's name. I don't schedule more than 6 hours per day, so if they manage to get in more productive work than that, then I am ahead. If they underestimated a task, get sick, have a company meeting, or have to pick up the kids early, then I have some padding to account for that.  If you notice, I also account for weekends, company holidays, and vacation time so I don't accidentally include those days in my schedule.  In the Staff sheet below, I only need the designer for a few days, and I only need one of the testers for part of the time.

The "Burndown" tab is where we see how the sprint is going to play out. There are columns for Planned Development, Design, and Test, as well as columns for the Actual hours. When the sprint starts, we see the planned columns start on December 3rd with the total work for each functional group. The totals for December 4 are calculated by subtracting the planned hours worked on the Staff page for December 3rd, so in this example, the developers planned to work 12 hours on the 3rd, so on December 4th there are 121-12 = 109 hours remaining.

The Actual Dev, Design, and Test columns are for recording remaining hours in the daily scrums. Each day, the team reduces that hours left to complete their tasks, and the total remaining hours are placed in the Actual Dev, Design, and Test columns. The result is that we can now track planned and actual progress for each functional group and know if we are on time, late, or ahead of schedule every day when we meet for the Scrum stand-up.

I filled in some sample hours worked in our sample sprint so you can see what the burndown chart might look like. In the chart we see the designer finishing on time. The developers start slowly, causing test to get behind, but they all catch up in the end and burndown the sprint overhead - bug fixes, deployments, UAT, and UAT Feedback - at the same rate.



My teams have delivered over a hundred sprints to production using this burndown system. When I start a new sprint I just copy the spreadsheet, fill in the sprint items and staff sheets, and then update the actual hours on the burndown page every day in scrum. When we are done, I save the sheet for the team's records in case someone wants to know what we delivered in a certain month, for example. I email a copy of the chart to all of team members every day, so they always know where we are, even if they are working remotely. This adaptation of sprint planning works well with real-world customers who are not really interested in our development methodology and just want to know when to expect their software release.


*To understand why I am suggesting that people should not be scheduled for a full eight hours each day, I recommend reading The Mythical Man Month.