![\"Example](\"http:\/\/farm5.static.flickr.com\/4114\/4878371197_77b54a2a1b.jpg\")
<\/p>\nAbout a month ago I was working with a team planning another iteration for the project, when we had an interesting discussion about how to manage our burndown.<\/p>\n
On all of our previous sprints, our burndowns were based on hours.\u00a0 That is, for each day of the sprint, team members would revise their estimates of the time left for any tasks they were working on.\u00a0 Typically (though not always), this means they were revising their estimates downward, and so the curve trends downward over the course of the sprint.\u00a0 At the end of the sprint, it ideally reaches zero on the last day as all the tasks are completed.<\/p>\n
<\/p>\n
On the projects for that particular company we have traditionally always burned down by hours.\u00a0 What I like about that is you get a real sense of it things are going astray.\u00a0 Because you often end up revising estimates upward early in a sprint, it’s a way to show that as you started to dive into tasks, things turned out to be more complicated than you expected.\u00a0 If that’s only happening on a few tasks, it’s not a big deal and while your burndown may initially be a little flat, the iteration is still probably not in jeopardy and you can usually recover.<\/p>\n
But if the burndown takes a significant jump up, perhaps because lots of tasks are taking longer than expected, then you know you have a serious problem that needs to be addressed.\u00a0 Burning down hours makes it easier to a team to raise this red flag, in a way that burning points down does not.<\/p>\n
The other thing that I like about burning down by hours is that it provides an easy way for the team to estimate in ranges.\u00a0 As I’ve indicated in many other posts and in talks I’ve done at conferences<\/a>, I love estimating in ranges (ie, 4-8 hours), instead of in single points (ie, 5 hours).\u00a0 Range estimation allows me to more accurately communicate the risk and uncertainty of a task.\u00a0 A wide range indicates larger risk and uncertainty than a narrow range.<\/p>\n When I make my initial estimates for an iteration in ranges, then I can put some nice boundaries around my burndown, as I’ve also discussed in other posts.<\/p>\n However, there is also a good case to be made for burning down in points.\u00a0 In this recent project, one team member had joined from another company and he made the case for burning down in points.\u00a0 His preference was based in part because burning down by hours can always be \u00abgamed\u00bb, ie, you can remove tasks from the iteration or just give misleading estimates in order to make the burndown look better.\u00a0 Furthermore, burning down by story points gives a clear indication of what is truly done, and at what point in an iteration the story is complete.\u00a0 By doing so, you keep the team more focused on what is truly done, and less focused on the way you got there (ie, the tasks estimates).\u00a0 No less than Jeff Sutherland, co-creator of Scrum has stated that \u00abThe best teams I work with burn down story points.\u00a0 They only burn down when a story is done.\u00bb<\/a><\/p>\n The rest of the team expressed some hesitation about going this route.\u00a0 In part because we liked the use of ranges and felt that it forced us to be more conservative in the stories and tasks we take on in a sprint.\u00a0 And in part because we felt the burndown would communicate less because most stories would not end up being done until the very end of the iteration.<\/p>\n However, our fears that no stories would get marked done until near the end of the sprint may have been symptomatic of another problem:\u00a0 our stories were simply too big.\u00a0 Jeff Sutherland notes in his blog post that \u00abto do this, the team needs to have small stories.\u00bb<\/a> If the story is not small enough for each developer to have multiple stories during the sprint, then burning down by points may not work well.\u00a0 I’ve heard Mike Cohn say that on average each developer should have 2-3 stories in an iteration, and I would say that is the minimum needed to make this approach work.\u00a0 I wonder if a slightly smaller breakdown so that everyone has 4-5 stories would probably work even better.<\/p>\n Both approaches have a lot of merit to them however, and so why not do both?\u00a0 I realized this was an option when I attended an Agile Richmond<\/a> talk recently, given by Guy Beaver, co-author of \u00abLean Agile Software Development\u00bb<\/a><\/p>\n Guy described using both charts on the same projects, in what he called an \u00abAgile V\u00bb burndown configuration.\u00a0 Basically you put a burndown of hours on the left, and a burnup of story points on the right.\u00a0 Ideally as your hours burndown goes to zero and your points burnup goes to 100% complete, you get a rough V shape at the end.\u00a0\u00a0 Some teams have even superimposed the two charts on one plot (using both an hours and points scale on the y-axis), to get an \u00abAgile X\u00bb shape in their burndowns\/burnups.<\/p>\n![\"An](\"https:\/\/agilityfeat.com\/wp-content\/uploads\/2011\/02\/BurndownGoneWrong.jpg\" "\\"BurndownGoneWrong\\"")
<\/a><\/p>\n
\nImage from this post by Guy Beaver on Agile Journal<\/a><\/em><\/p>\n