Posts Tagged ‘agile’

Improved Agile Release Burndown Metric Reveals More Stories about Teams

September 28, 2015

The Done-Done Completion Rate tells us some interesting information about how our agile teams are doing on a sprint-by-sprint basis.  However, it doesn’t help us to understand whether they will actually hit their next milestone.  The trouble is, the current version that they’re working on may still not have all its scope defined.  That’s all agile and fine and everything, but the reality is, sometimes we want to know if we’re going to hit a date or not.

As mentioned previously, here at Central 1, we use JIRA to manage our agile backlogs.  This tool comes with a handy release burndown chart, which shows how a team is progressing against their release goal.  For example, the chart below illustrates a team who started their version before adding any stories to it.  However, once started, they burned a portion of the release with each sprint, eventually leading to a successful release.  In sprint 27, they added a little scope, effectively moving the goalpost.


The trouble with this chart is that it supposes that the team is planning their releases (versions in JIRA).  What about teams that have multiple concurrent releases, or those that aren’t really using releases at all.  Are the teams leaking defects into the backlog?  Are they expanding the scope of the current release?

In order to answer these questions, we need to include the unversioned backlog.  I’m considering a metric that I have given the catchy moniker, “Net Burndown for the Most Active Committed Release.”  This starts out with the chart above for the release upon which the team is making the most progress.  Any change in any other releases is ignored, so a team could be planning the next release without affecting their net burndown.  However, if they leak stories, defects or tasks into the backlog without associating them with a release, those items are assumed to be in the current release and included in the net burndown.  Sometimes that’s bad, and sometimes it’s good.  Finally, any unestimated items are given the average number of points for items of that type.

Here is how the chart looks for one team.  This team is somewhat disciplined about using versions, but as discussed before, they leak quite a few defects, and may or may not assign them to a version.  In the chart, the blue area represents the same information as the JIRA release burndown chart.  The red area adds in the backlog outside the release, and you can see that it tends to dominate the blue for this team.  Finally, the green area represents all the unestimated issues (mostly bugs).


In some cases, like August 12th, the negative progress in the backlog (about -50 points) dominates what appears to have been pretty good progress in the release (about 50 points).  The unestimated issues (about -30 points) leaked onto the backlog make the story even bleaker, and we can see that the team is not making substantial progress toward their release after all.

Contrast this team with a second team, who take a more disciplined approach overall.  The team did some sort of a huge change in their versions in June, which cuts off the chart.  However, since then, we can see that the team leaves very few unestimated issues, and tends to assign issues to releases, rather than working on the backlog directly.  They’re not perfect, however, and struggle occasionally to maintain their velocity; comparing with their Done-Done Completion chart, we can see that this was actually a struggle, as opposed to a planned dip for vacations.  They also seem to be letting go of the versions a little in more recent sprints.