By Ajay Emmanuel | May 5, 2017
The Burndown chart is very simple. It is easy to explain, easy to understand. But there are pitfalls observed in the way teams adopt and use the burn-down chart for tracking the Sprint progress.
The most common issue is of the Cliff-hanger Burn-down chart. When we first started off using JIRA Agile, we used Epics to specify large feature-sets ,stories for the individual capabilities of the larger feature, and technical tasks (JIRA sub-tasks) for individual work items. Each and every sub task had a specific story point specified which totaled up to the parent task’s (User Story) story points.
It turns out that using such an approach you land up with a cliffhanger burndown chart in JIRA. All though you expect that completion sub-tasks would decrease the remaining story points ,it turns out that the story point burns down when the User story is marked as resolved.( near the end of the sprint. )
Stories are typically bigger items than tasks. Stories are also considered as done only when all tasks are completed. This leads to stairs in the Burndown chart. Such stairs are usually not evaluated correctly. Especially management reads them as ‘no progress’ while they mean ‘effort continues, it has not been completed yet’. Steps could be smaller if stories are broken down in an appropriate way.
JIRA Burn-Down Chart Best Practices
Agile out of the box does suggest NOT to estimate story points on sub-task level, but keep them on the story level only. The views and reports on agile boards are currently optimized for that.
Many Scrum teams separate estimation (which is used for measuring the size of a backlog and calculating velocity) from tracking (which is often the burndown of hours used during the Sprint to be sure we’re not way off the pace necessary to complete the stories in the Sprint time box), and use different units for each.
A common approach is to estimate tasks in Story Points, then track tasks using hours. JIRA Agile therefore gives you the flexibility to set your estimation and tracking statistics differently, depending on what best suits your team.
To have a meaningful Sprint burn-down chart, the recommendation is that team members stick the practice of updating “Remaining Estimate” field value directly and manually ever day instead of using “Log work” facility. And, if we ensure that “Estimation Statistic” is configured to use “Story Points” for estimation and “Remaining Time” for time tracking, then, Burn-down chart automatically uses the total “Remaining Estimate” of all the tasks mapping to all the stories planned for a sprint.
This means, there would never be a need for us to change Estimate field at story level since they are anyway relative size of stories. Only thing team needs to worry is to update “Remaining Estimate” field of all the technical tasks they are working every day.
The only time we may need to use “Time Spent” and hence “Log work” facility is if we really need to track if the team is spending extra time in doing unproductive work other than their technical tasks.
This includes waiting time, dependency wait, spending time on understanding scrappy code, etc… and all this is considered software waste in Lean thinking. This way, we can identify waste and possibly source of waste (by entering meaningful comments when we log extra work) and taking proactive action.
VIEW26 offers capabilities that extend your QA analytics toolkit in ways that bring instant insights and reporting. See for yourself what VIEW26 can bring to you.