Release Burn Down Brought to Life
August 19th, 2015
Inspired by the blog of Mike Cohn [Coh08] “Improving On Traditional Release Burndown Charts” I created a time lapsed version of it. It also nicely demonstrates that forecasts of “What will be finished?” (at a certain time) get better as the project progresses.
The improved traditional release burn down chart clearly show what (a) is finished (light green), (b) what will very likely be finished (dark green), (c) what will perhaps be finished, and perhaps not (orange), and (d) what almost is guaranteed not to be finished (red).
This knowledge supports product owners in ordering the backlog based on the current knowledge.
Simulation
The result is obtained doing a Monte Carlo simulation of a toy project, using a fixed product backlog of around 100 backlog items with various sized items. The amount of work realized also varies per projectday based on a simple uniform probability distribution.
Forecasting is done using a ‘worst’ velocity and a ‘best’ velocity. Both are determined using only the last 3 velocities, i.e. only the last 3 sprints are considered.
The 2 grey lines represent the height of the orange part of the backlog, i.e. the backlog items that might be or not be finished. This also indicates the uncertainty over time of what actually will be delivered by the team at the given time.
The Making Of…
The movie above has been created using GNU plot [GNU Plot] for drawing the charts, and ffmpeg [ffmpeg] has been used to creat the time lapsed movie from the set of charts.
Result
Over time the difference between the 2 grey lines gets smaller, a clear indication of improving predictability and reduction of risk. Also, the movie shows that the final set of backlog items done is well between the 2 grey lines from the start of the project.
This looks very similar to the ‘Cone of Uncertainty’. Besides that the shape of the grey lines only remotely resembles a cone, another difference is that the above simulation merely takes statistical chances into account. The fact that the team gains more knowledge and insight over time, is not considered in the simulation, whereas it is an important factor in the ‘Cone of Uncertainty’.
References
[Coh08] “Improving On Traditional Release Burndown Charts“, Mike Cohn, June 2008, https://www.mountaingoatsoftware.com/blog/improving-on-traditional-release-burndown-charts
[GNU Plot] Gnu plot version 5.0, “A portable command-line driven graphing utility“, http://www.gnuplot.info
[ffmpeg] “A complete, cross-platform solution to record, convert and stream audio and video“, https://ffmpeg.org
Look at our consultancy services, training offers and careers below or contact us at info@xebia.com
Comments
And thus the myth “we do agile, we can’t plan” is not only debunked, but replaced with a useful tool for forecasting. How about a bit of noise on the backlog? Though it hardly matters when you swap unbuilt items, it will have effect when the feature is built.
Probably only shows that at the end of the time there are new wishes plus the left overs due to variance in the velocity.
(Note to self: organize sizing of next 100 items and put up a burn down in Pieter-style in the board room)
Err… how can “highly likely” continually get eaten up by ‘possible’. This shows these are misnamed, and ultimately this is a volatile tracking/forecasting tool that’s likely to cause unnecessary anxiety. Rather extrapolate overall avg velocity to date through latest scope/time point to forecast most likely end scope. As depicted in Scrum From The Trenches (Henrik Kniberg).
Myles, thanks for your feedback. The tool is doing exactly that!
Highly Likely is the part of scope that the team will deliver assuming that from that sprint onward they will do no better than their worst sprint.
The video shows a time-lapse as if a snapshot is taken just after each sprint has ended,
After each sprint it extrapolates using the average velocity to date what part of the scope will be delivered at a fixed date. Because the actual velocity of the team will fluctuate (it never is a constant) what scope will be delivered on average will also vary.
Because of these fluctuations having an average velocity is not enough. The spread around the average is important as well. This is depicted using the Highly Likely and Highly Unlikely scope parts.
At the end of each sprint, the team will have new insights into their average velocity and its spread. This also causes the continuously changes boundaries between Possible an Highly Likely.