JIRA Just Cant Do Burn-down Charts!
I have been working reasonably extensively with JIRA since 2012. My first interaction with JIRA was with a Mobile Network Operator who was using it as a feature & bug tracking tool. I continued to work with JIRA as I transitioned from the Mobile Handset industry to the Automotive industry. Over the last five years, many Automotive OEMs and Tier-1’s have started using JIRA. The scope of use varies, but many have started using JIRA as a development & release tracking tool. Many of these organizations are also experimenting with variants of Agile “scrum” methodology, and are using this tool to track sprints.
Unfortunately, this is where the limitations of JIRA become quite apparent. My experience with JIRA is that it is a great tool for bug tracking, or simple task tracking. It is also a good tool to track development of simple software products. For anything more complicated than a simple software app development, JIRA is woefully inadequate. It is also quite unsuitable for agile scrum development.
The Problem: Incorrect Burn-down Charts
For a tool that claims to be “Agile”, it is surprisingly difficult in JIRA to get an accurate burndown chart. A burndown chart is a simple graph that shows progress in a sprint by plotting a line graph of remaining effort. It just shows how much work is remaining, over time.
To illustrate the problem, I created a simple project in JIRA and called it “Project X”. I assumned the project consisted of a hypothetical unit conversion application for your smartphone. The features of this application are:-
- Conversion of units from metric to imperial & vice-versa
- Calculation of gas mileage/fuel efficiency of a vehicle
- Historical reports and export of data
I added the high-level features of the application as epics.
I then created simple “user stories” under those epics for adding the features of length conversion, volume conversion and temperature conversion. I added an estimate of 1 story point for each of these.
NOTE: The details of “story point” estimation is a separate topic, but this blog by Mike Cohn is a great introduction.
I then went to JIRA’s “Backlog” tab and proceeded to create three sprints
- PX Sprint 1– 2 week sprint from 29/Jul/2023 to 12/Aug/2023
- PX Sprint 2–2 week sprint from 13/Aug/23 to 27/Aug/23
- PX Sprint 3–2 week sprint from 28/Aug/23 to 11/Sep/23
Finally, I marked the three user stories for PX Sprint-1.
As you can see above, each user story has 1 Story Point. So the Burndown chart of Sprint-1 should start at 3, and then go down to 0 at the end of the sprint. Something like this :-
However, when I go into JIRA’s “Reports” and select Burndown Chart, I get this.
JIRA’s burndown chart takes into account the weekends, (which is good) however, it fails to plot the actual burndown correctly. This screenshot was taken on July 31st. JIRA seems to assume that 3 story points were remaining on July-29th, then all of the three got completed (burned down), and one story point was added on July-31st. Surprisingly, all three user stories were open, as shown below. I did not mark then as “Done”.
After looking at the JIRA default board, I got a hint at why JIRA’s burndown chart was misbehaving. It seems like JIRA does not count User Stories that are not alredy in a “In Progress” state. After marking all the three User Stories as “In Progress”, the burndown chart changed and showed all three.
It still shows (incorrectly) that all three stories were burnt down on the first day itself, and then one story was added back. I could not decipher the reason for this.
However, not showing user stories in “To Do” states seems to be a very basic flaw in JIRA, which, I am surprised, has not been reported by anyone.
I then proceeded to mark one of my user stories “Done”. The expectation was that JIRA burndown recognizes this and shows a reduction in the remaining work in the burndown chart. Strangely, it had absolutely no impact on the burndown chart. I dug deeper, and I found one possible cause — it seems like when I marked a user story “Done”, JIRA did not mark it as “resolved”.
So I did a Google search on this and found this on the Atlassian community forum. I followed the steps described and added the “post function” to mark my stories as “Resolved”.
This is especially frustrating because it takes just 5 minutes to write a excel formula to show a proper burndown chart with this same data. Other Scrum trakcing tools that I have used — Scrumworks and Ralliy for e.g. — do not have this basic problem. Scrumworks in particular, is pretty good at showing burndowns. Ironically, if you search for “scrum works” on Google, the first result is JIRA and not Scrumworks!
Besides this basic problem in depicting a burndown chart, a proper Scrum tracking tool would have a configuration for the team velocity. This velocity should then be used to predict the ideal burndown. For e.g. if there is 1 person working on this app, and we know from historical records, that this person’s velocity is 3 story points per sprint, then we would be burning down the user stories at a rate of about 0.21 story points per day. However, if there were two people working on this, then we would expect a higher rate of burning down the user stories. JIRA however, does not consider the team velocity at all. At least I could not find any configuration that lets me input the team velocity.
