Burndown charts in Jira ?

[Deleted user]

Can someone please suggest / what have done to be able to see the burn-down charts  in terms of progress made in the sub tasks ? Currently in my board the estimation is set at story point and time tracking is turned on ( Remaining Estimates and Time Spent). Story's were estimated as story point before staring the Sprint. But the burn-down chart isn't reflecting the time logged against the sub tasks.

[Thomas Deiler]

Dear @[deleted],

the behavior you observed is implemented by Atlassian closest as possible as the few rules of Scrum provide.

You never burn down working hours. This is a time related measurement. Instead you burn down something relative, called Story Points. Every team has an own unique understanding of what one SP is for them - you cannot compare them with values of other teams.

And in the end it is not that important how many time you have logged in total to one story, because the logged work of all stories at the end of the sprint will be more or less 7h per team mate multiplied with working days of one sprint.

The risk in doing this is, that some individuals try to calculate a ratio of story points <> working hours. For what? You will not be happy - this ratio is not constant.

The most important goal of doing a sprint is to deliver business value at the end of it. Was this achieved? Is the customer satisfied? Perfect! Your have a winning team. Assist them, that they can improve themselves.

And just a side note: A sprint burn down is in its design purpose only team internal and not made for the eyes of any others. Managers never should see them. But they are allowed to see a Release or Epic Burndown (job of the product owner).

So long

Thomas

[Nic Brough -Adaptavist-]

One phrase that stuck in my head is that Story points are a measure of complexity, not time.

[Thomas Deiler]

Dear @Nic Brough -Adaptavist-,

I cannot recommend to set SP equal complexity. If you do, your velocity will vary dramatically.

Only very experience teams, that have proven over a long period of time that they are elite troopers, should 'weight' in complexity.

So long

Thomas

[Nic Brough -Adaptavist-]

Oh, very much so. 

I think it's something good Scrum teams drift or evolve into.  Even if you start with the absolutely dreadful "1 story point = X hours", if you keep doing proper reviews, refining estimations and paying attention to velocity, then, one day, you realise the story point and hours on a good number of your issues are totally unrelated!  Whilst you're still delivering roughly what you commit to.

[Thomas Deiler]

Dear @Nic Brough -Adaptavist-,

I have to disagree. Especially for new starter teams, it is important to teach them from the very beginning to estimate relative sizes. If you equal it to time, they will hardly unlearn it later.

So long

Thomas

[Nic Brough -Adaptavist-]

No, I'm not saying teach them time/SP, you should always teach them SP are complexity and size and not time! Never time! 

But some teams start with time/SP.  And we inherit that.   If they do scrum well long enough, they learn.  We should always be encouraging them to do so.

(Well, ok, there's one exception, but if you do it, don't use it for velocity or scrum, because it's not)