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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Creating a burndown report and estimates

Before we start our sprints, we create stories and sub-tasks. We put estimates on the sub-tasks. The issue is that because the estimate isn't done at the story level, our burndown report doesn't have the grey line showing the sprint trajectory. We attempted to mitigate this by rolling our estimates manually (by editing the story and adding estimates to the Original Estimate field) to the story. That had two unintended consequences: (1) Our estimates were doubled at the sprint level (2) No grey, burndown line was created because estimates aren't showing as an "Estimated Duration) in the burndown report.


- how does on add an estimate to a story that works for a burndown chart?

- why are the estimates being double counted at the sprint level and is there a way to mitigate that considering we need estimates both on stories (for burndown) and sub-tasks (as per our estimating process)


1 answer

0 votes

Do not put sprint estimates on sub-tasks. 

Scrum burn down is done on what you committed to do for your Product Owner at the beginning of the sprint.  You don't commit to sub-tasks, you commit to items at the story level.  Sub-tasks are a way for developers to break up a story for several reasons, but you don't commit to them. 

So Jira is only looking at the story level estimates.  It gives you the correct burn-down chart based on the stories you have estimated on (the chart, of course, ignores sub-tasks because they are utterly irrelevant to burn-down).  The rest of Jira then double-counts because it just reads every estimate.

There are some ways you can do estimates on sub-tasks and still do scrum and have the estimates work.  There are several estimation strategies, but they all require other fields to be calculated and used differently, and most people instinctively go for a strategy that still doesn't work.  The only one I've seen work properly relies on starting with estimates on story-level items.

thanks! what field(s) should be used to estimate at a story level so that a correct burndown line appears on the chart?

I cannot tell you that, I do not know how your teams work, or how they estimate things, but I can get it down to a quite simple question.

Scrum needs to work with numbers.  Humans see a lot of numbers in a lot of different ways but Jira needs a definitive number.  So you should look at the two basic options:

  • Number of (milli)seconds you think it might take - use the "time tracking" option
  • Number of <whatever> estimation units.

The second one there translates into:

  • In jira speak; any numeric field, (including Story points)
  • In human speak: any number you can put on something that might show us how much work there is to be done

But, to get a "correct burndown", you should slelect a number field to burn down on, and then look at the last column on your board to establish when burn-down happens.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events