Creating a burndown report and estimates

Question

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.

Questions:

- 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)

thanks

Nic Brough -Adaptavist- · Answer

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.

Matthew Hosek_1khund · Answer

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

Nic Brough -Adaptavist- · Answer

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.