I want to use this month’s blog posting to introduce a type of burndown (and burnup) chart that I find useful. I’ve been drawing this style of burndown chart for years and have coached many of my clients to do the same. Unfortunately, we’ve had to draw it either by hand or in tools like Visio and OmniGraffle because the agile tool vendors haven’t (to my knowledge) hit on this idea yet. I’m hopeful that some of them will see this posting, decide this is a good visualization, and incorporate it into their products.
The classic Scrum release burndown chart is good at showing whether a team will finish “on time” as can be seen in the following example burndown chart:
A release burndown chart such as this one shows sprints on the horizontal axis and can show story points or ideal days on the vertical. It is updated once per sprint to show the team’s net progress that sprint. A team’s net progress is the amount of work they finished net of any changes in scope. So a team that completes 30 points of work but that has 10 points added to their product backlog will show net progress of 20.
But while a traditional release burndown chart excels at showing whether a team is on pace to finishing on time, it is not very good at showing what will be included in that “on time” delivery. To see this, imagine two teams that each start with 200 story points of work. The first team finishes twenty points of work for each of ten sprints. The second team is incompetent and rather than completing twenty points each sprint they drop twenty points of scope each sprint. The two burndown charts will be identical–perfect lines descending over ten sprints from 200 to 0.
At one level this is OK: the burndown chart shows whether a team will be finished (or by when the will be finished). The simplicity of the standard release burndown chart has much in its favor.
It isn’t hard, though, to extend a release burndown chart to also show what will be in the product by the final sprint. Look at the next figure, which is a hypothetical example of an eCommerce product.
In this figure, you can see the burndown is tracked in the normal way through the end of the current sprint, the seventh. The company desires to release this product after the fourteenth two-week sprint. The right side of the burndown chart shows the team’s product backlog with the highest priority theme (“Returns”) at the top. This top block represents some “must-have” user stories related to returning purchased items. Below that is a theme for gift wrapping purchased items, followed by some “nice to have” aspects of returning items. At the bottom right is the Coupons theme.
Extending out from the team’s current position at the end of the seventh sprint are four lines. These lines represent the following:
- The team’s current position, drawn as a horizontal line from the current burndown position over to the product backlog. This tells us what is in the product so far. We can see that the mandatory return user stories and the gift wrap user stories are finished and that the team is partially into the nice-to-have return user stories.
- A black, dashed line showing the team’s most likely finish. This is the first of three trend lines meant to show the likely range of work the team might deliver. To draw a team’s most likely finish use the team’s long-term average velocity. You can define “long-term average velocity” in whatever way you want but my preference is to use the average velocity of the last 8-12 sprints. Pick the number of historical sprints that is most suitable for your team based on how long the sprints are and how long the team stays together.
- A pessimistic forecast of the amount of functionality that may be delivered. I recommend forecasting this based on a team’s worst-case but likely velocity. Calculate this by averaging the worst three or so velocities chosen among the same 8-12 iterations you looked back at to determine the team’s long-term average velocity.
- An optimistic forecast of the amount of functionality that may be delivered. Calculate this in the same was as in the pessimistic case but use the three (or so) best velocities of the team.
The figures in this blog are static images I’ve cut from a presentation. If you apply this technique for your team, the backlog items on the right should be clickable, allowing users to drill down into a product backlog theme to see specifically which items (typically user stories) make up the backlog.
By producing a single chart that shows both a team’s rate of progress (its burndown) and the product backlog, we have a single visualization that shows both when a team is likely to finish and what features will be in the product by that time. This makes is easier for product owners to make scope vs. schedule tradeoff decisions.
Check back in a few weeks when I’ll show an even more powerful technique for visualizing large product backlogs.
Tags: agile release planning, metrics, sprint burndown chart
Mike,
honest and open communication is a big value.
And ‘managing the anxiety’ of the client is important too.
Don’t you think that saying ‘we will finish between tomorrow and next decade’ is like saying ‘our detailed planning chart says we will finish on november 24th at 4pm (== bullshit)’?
Thank you and congrats for your contribution,
PierG
http://pierg.wordpress.com
Hi Pier–
Absolutely. The goal of a planning process should be to create knowledge and plans that the business can use to make reliable decisions. Saying “sometime in the next decade” is too imprecise to be useful.
–Mike
Hi Mike,
We also think that Release burndown chart is very important for any project. Currently we are developing a tool for SCRUM in which you can see sprint burndown, release burndown and also velocity chart. We can estimate story by points. When any story is added by product owner(PO), he can send a request to team members to estimate stories. Each team members estimate stories which is not visible to each other. Then PO finalize the point of the story by seeing all these points. PO can re-estimate stories if he think there is very much variation in the points estimated by the team members. We can also do sprint planning. PO prioritize stories and team members bring them to sprint from the top. Then they estimate them again but at this time in hours(). During sprint team members give their time entry each day from this information the system produce sprint burndown. We can create release and can assign sprints to any release. As we are assigning sprint to release and again assign stories to sprint, the system produce release burndown automatically. We are trying to give all facilities of SCRUM in our tool. Please explore our project and suggest us if you feel that we can give additional feature to our project.
Here is the URL of our project -
http://www.scrumpad.com
- Titu
Hi Titu–
ScrumPad looks like an interesting new product. There are, at last count, over fifty existing product backlog management tools. I wish you luck as you enter a crowded field.
–Mike
ScrumWorks have something they call a product burndown, where you can select multiple releases and show the burndown. It also shows you how much extra work (or estimation changes) that has been added/removed to/from the backlog between sprints. By using the trend of work added/removed and the sprint burndown they give you and estimate of how many sprints you need to finish to release your product. All of this is represented i a chart. It’s rather difficult to explain, so I’ve put a screenshot here: http://blog.torresdal.net/images/productburndown.jpg
Hi Jon–
I’m familiar that style of burndown chart. (I call it a “burndown bar chart.”) In fact, Danube added it to ScrumWorks after reading about it here a few years ago: http://www.mountaingoatsoftware.com/alt_releaseburndown
Hopefully, they’ll do the same with I’ve shown in this blog posting.
-Mike
Hi Mike,
Cool. I forwarded this to the ScrumWorks team just in case they haven’t discovered your post yet (unlikely I know
). We’re using their tool, so it would be great to have this chart available…
I like the information, but I am not sure it belongs in a single chart. I am not sure it doesn’t either so I will need to think on that for a while. A couple of observations, though. First, statistically you should discount the worst and best numbers in a set. So for your estimated velocity you should likely ignore the worst and best velocity (you know the week when everyone had the flu, or when management and marketing where brainstorming next years products so there were fewer distractions). The second observation is that you appear to have pretty detailed long term planning. Have you described how you do long range planning somewhere (another blog post)? Our long range planning is very high level and I would not have the information (i.e. Story Point Estimates) to create the chart you have shown.
Pat O
Hi Pat–
I’m fine with you leaving out the best and worst velocities. I think I mentioned in the post that I don’t really care how a particular team determines *their* best and worst likely predictions of velocity as long as they do. I’ve covered other ways of determining it in my Agile Estimating and Planning book, which is also where I address how to do the longer-term planning and usefulness of putting story point (or ideal day) estimates on the bulk of the product backlog. The key point for me is that a team should do something to approximate having a confidence interval around their velocity. Since a team is unlikely to have enough data themselves to make a statistically significant confidence interval, I’m OK with just faking it in some reasonable manner.
When I was doing this as a VP of Development at a company and could collect whatever data I wanted over the long term, I had a ton of velocity data and knew a true standard deviation for the company as a whole. Teams could apply that to their own mean velocity and at least have something useful.
Improving On Traditional Release Burndown Charts…
Mike Cohn suggests an improvement to traditional release burndown chart to map the team progress to the backlog directly. Idea is be able to answer what will be ready and when….
This is one reason I always prefer burn-UP charts. They allow me to add a second line (or a bar) to the graph which is the target scope. If it’s a bar, it can also be sectioned to show what sort of scope it is made up of (eg. how much is returns, how much is gift wrap, and, importantly, how much is there because of regressions that we’d like to fix at some future stage). Much the same as the bar on the right of your chart. Importantly, however, a burn-up allows me to adjust this bar every iteration to show the new make-up of scope and if things have been added/removed. I can also project when each part will be finished by comparing it’s height on the chart and the rate of scope consumption.
I don’t think I’ve ever said so on this blog, but I have said in some classes and conference sessions that I think burn UP charts are where we end up in the future. They can be more expressive. I’m torn by this because I personally think burning down is “better”. (One reason: We already feel too free to move the end goal of a project; making it even easier with burnup charts will just make some current scope management problems worse.) But, I’m firmly convinced that when my grandkids are drawing these charts they will be burning up not down. Still, everything in the sample figure I provided applies–whether we burn up or down, putting a stacked product backlog along the right side helps make the chart more expressive.
Hi,
Based on Mike’s book, I have built a Release burndown so that you can also see what is added and removed. I have tested it and it seems to work:
http://gujiconsulting.googlepages.com/ReleaseBurndownBarChartv0.9.xls
Any feedback is welcome!
Christophe
based on this example i produced a single chart with both the burndown and product backlog on using excel.
i’m happy to share if anyones interested
Paul
Hi Mike,
I’ve read you book “Agile Estimation and Planning” and this blog. What I’m missing is an elegant way of combining a burndown chart and the MoSCoW priorities. In most burndown charts the storypoints on the vertical axis are descending from (say) 200 to 0. That is quite a theoretical approach. In reality there are, say, 150 must haves, 50 should haves and 50 could haves. So finishing up somewhere between 150 and 250 points done could be considered as “good enoughâ€. The bottomline in the chart is fuzzy now. The goal is no longer: finishing with 0 points left. The goal is: finishing with all the must-haves done and as much as should-haves and could-haves when there is some time left.
I’ve done some experiments in plotting this in a burndown chart. What you will get is an area where to finish instead of a single point. Not very elegant and hard to explain to board members. Any ideas? All feedback is welcome.
Kind Regards,
Anthony
Hi Anthony–
What I would do is draw the burndown as shown in the second figure in this post (with the backlog themes shown on the side). But I would then draw a couple of horizontal regions coming across. Imagine three horizontal lines: One shows where the must haves end (above the line are the must-haves), another shows where the should-haves end and the last line shows where the could-haves end. Your goal is to end anywhere within those lines while striving to get as far as possible. You could even shade the three regions for clarity.