Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Avoiding a cliff-hanger burndown chart in JIRA

 

 

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.

 

view26-charts.jpeg

 

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.

 

3 comments

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?

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 Community Leader Mar 31, 2020

Nice tips on managing JIRA burn-down chart!

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Opsgenie

Opsgenie and Amazon team up to launch new DevOps Guru integration - now available!

We’re proud to announce that our integration with Amazon DevOps Guru is now live. The Amazon and Opsgenie product teams have worked together to build a deep integration between Opsgenie and the new...

252 views 0 8
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you