I work with exceptionally compressed project timelines. Generally the whole project comes in at about two weeks, debugging and all. In this context Jira’s burndown charts are less than ideal. Here’s an example:
There are a few things wrong here:
- The burndown chart looks increasingly bad for the first few days of the project, then takes a sudden plunge (which is good, but it’s not clear what changed).
- The last several days all look odd because nothing seems to be happening (it looks like the project is done).
The start of the burndown looks the way it does because of the compressed time frame of the project. Some of the tickets are 5 or even 8 points (more than a day) so of course progress is uneven.
Nothing appears to be happening for the last half of the project because that’s when we test the final product; numerous small issues are reported and corrected, and often they don’t get points assigned to them.
To improve the situation I wrote a tool to generate my own burndown charts. Compare the above to this:
It’s a stacked area chart that includes a separate line for each possible status a ticket can have. There are several improvements here:
- The weekends are shown, marked in gray. Note how some work is done on the 15th, even though it’s a Sunday. We don’t (often) expect developers to work on weekends, but they sometimes do.
- Burndowns are shown for each possible status of a ticket. The beginning of the project is much clearer: Obviously the developers tackled some larger tickets early on (the quick drop in the “Open” graph) which slowed the progress of tickets to “Closed.” There was a buildup of tickets waiting for peer review as well.
- I show the “Closed” tickets as well as the rest of the statuses. This helps especially when projects grow, either because tickets are burned up or just added. Note the increase of the scope on the 12th and 13th.
- For all tickets with no points assigned, I assume 1 point. That’s where the bug tickets at the end of the project come in. Note how the project grows steadily from the 18th on as bugs are reported. The developers mostly keep up with the reported bugs, although they fall a bit behind on the 20th, and catch up on the 23rd.
It’s also important to note that over eighty bugs were found between the 16th and the 24th. That’s too many, and we need to work on that.
The tool I wrote gathers data retroactively, so I can run it at any time. It has a method for getting all the tickets in a particular sprint, but it will work on any set of tickets. If anyone wants a copy I can tidy it up for distribution. It’s written in Revolution