Avoiding a cliff-hanger burndown chart in JIRA

[#1]

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.

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.

JIRA Burn-Down Chart Best Practices

(refer :Atlassian community post)

Many Scrum teams separate estimation(which is used for measuring the size of a backlog and calculating velocity) from tracking (which is often the burn-down 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 and taking proactive action.

[Deleted user]

I could find option to use Remaining Estimate as Burdown input when Board is in Story Points, neither couldn't field for Remaining Estimate was visible when the only estimate for user story is in story points. Can please help with that?

[Nick Scott]

I think there is a slight misunderstanding.

Estimate Stories in Story Points (hence the name), and estimate Tasks (and sub-tasks, which is a Jira specific concept to merely differentiate for a child task of a parent) in hours.

Then in the Board configuration set the Estimation Statistic to Story Points and the Time Tracking to "Remaining Estimate and Time Spent"

[Taranjeet Singh]

Nice tips on managing JIRA burn-down chart!

[Jess Hines]

I'm here in 2021 wondering if this works in Jira 8.5. 

I created a story, set Original Estimate to 18h, and then in the quick detail view from the board, updated Remaining Estimate to 6h. When I go to the big view of the story to look at Time Tracking, it shows Estimated = 6 and Remaining = 6.

Only if I do Log Work and put in the time does the Time Tracking show original, completed, and remaining accurately.

So was the feature mentioned in this article, updating only the Remaining Estimate field, removed in later versions, or is there something I need to set up or configure differently?

[Nick Scott]

The feature was not removed.

Are you sure your Quick Detail View is configured to display "Original Estimate" and not a field called say "Estimate" (which is a different field and is based on the value on the board you set under "Estimation" -> Estimation Statistic (so that could be Story Points for example)

[Jess Hines]

My Quick Detail shows "Estimate" which is story points, and also "Remaining."

These are my board settings:

I think perhaps the main thing that's missing here or in the official Jira documentation, which says:

...values only burn down when users enter Time Spent or set the Remaining Estimate to a new value.

is something to the effect that "updating Remaining Estimate tracks those changes in the background" because it sounds like that's what it's doing but it's not apparent that it does that when you view an issue in full view, and Estimated and Remaining are the same. Whereas if you use "Log work", then you get Estimated, Remaining, and Logged, which makes sense. It would be nice if updating Remaining Estimate resulted in something like Original Estimate and then Remaining. 

[Nick Scott]

In that view is that a parent ticket and the children (sub-tasks) is where time is being tracked?

[Jess Hines]

Nope, it's just a story, no subtasks.

[Nick Scott]

So, you are estimating the Story using Story Points, but at the same time putting time against the story itself with no sub-tasks?

[Jess Hines]

Yes, some stories will have subtasks, but some don't need it, i.e. they're small enough already.

[Nick Scott]

Hopefully it's clear to you now that nothing has changed here and the original article still applies.

[Jess Hines]

Well, not really. I guess my question boils down to this:

If you're just updating the Remaining Estimate field (for example, I put in 2d on a story when the sprint started, then at the end of the first day change it to 8h, then after the second day change it to 0h), does Jira save every past value in order to create the burndown chart? If not, how would it know what it started at?

Does it just look at the total of Remaining Estimate for the sprint, log that at the end of a day, and then do that each day?

[Nick Scott]

It basically calculates the sum of the remaining time for all work in a sprint every minute and renders it on the burndown chart. I don't know if it is literally every minute but it is much more frequently than daily.