Epic Burndown Chart not working - subtasks are ignored

[P_]

I found accidentally that the Epic burndown feature is not showing proper data, it simply ignores the sub-task estimations that are rolled up at the story level. It is inconsistent with Sprint Burndown charts, which (when set to work with time estimates) correctly shows time spent and remaining based on the subtasks.

So in other words, when you estimate effort for your subtasks only, which we do, we see the aggregated effort at the story level. However, in the Epic Burndown report, all our stories are UNESTIMATED.

[Nic Brough -Adaptavist-]

Actually, it is.  In Scrum, you do not estimate sub-tasks.  You can see hour estimates rolled up if you use them, but estimation by teams is done at the level of the story, not the sub-task.  Remember that you're committing to doing the story, not the sub-tasks underneath it, so the measurement should be at that level.  Burndown functions at that level too - is the story done or not?

Epics look down to their stories to get the estimates.  To "fix" this, you need to estimate at story level.  Either do that directly, or script something that rolls your estimates from the sub-tasks up to the story and tell your charts that that is the estimation field, not the one you are putting the estimates into, but, if you do that, be VERY careful NOT to use the same field you use on sub-tasks for estimates

[P_]

Well, that depends. Scrum only prescribes to estimate backlog items. The problem is the inconsistency in Jira: sprint burndown charts do use the estimates in sub-tasks, i.e. when you have a story with sub-tasks estimated as 20 hours, it will be correctly shown and the amount decreases as your team members log their time spent. 

Also in practice, I have never seen a company that would use effort estimates (time) at the story level, that makes only sense if you estimate in story points.

Teams typically use SPs for stories but individual sub-tasks have time estimates set by the assigned developers, which is the point of story points: individual effort estimates between programmers van vary but all understand the relative size.

[Nic Brough -Adaptavist-]

I think you've misunderstood.

You are absolutely right that Scrum does proscribe that you estimate backlog items.  What I think you have missed is what a backlog item is.  It is something that your product owner would like you to do and an item that you can commit to doing in a sprint.

Not a sub-task.  Sub-tasks are a convenience to help break up a backlog item for (one of quite a number of reasons).  They are not a backlog item.

So, yes, you're right, Scrum asks you to estimate the backlog items.  So estimate your stories.  Not the sub-tasks, because they're not backlog items.

[P_]

Again, so why the sprint burndown chart correctly shows effort changes based on original estimation and time spent? One would expect consistency. 

I think you are missing the point - let's say you want a story to be estimated to 16 hours. It is completely irrelevant if it is entered at a story level or it results from rolling up of the underlying items, it indicates the total effort no matter where it comes from. And Jira supports that because the sub-task effort is rolled up at the story level, you can filter by Sum of remaining effort and, as I said, Sprint burndown chart works as expected if you are working with effort estimates in hours and only at the sub-task level.

I have worked for several large, multinational IT corporations. Not a single one was using only stories because there are always more people working on a story, and each of them works on a different (sub)task estimated in hours.

My point is - in true, pure Scrum, I agree you do not need that, your story is either done or it is not. But in reality, teams need time tracking for effort tracking, capacity planning, invoicing purposes etc and the story level does not provide enough granularity.

[Nic Brough -Adaptavist-]

I am not missing the point, I am explaining what you are seeing and why it happens this way.

I know it is counter-intuitive, I know you've seen lots of places (try to) work this way, but it is wrong and hence Jira does not work when you do it. 

The estimates you put in front of the product owner, and hence commit to, are on stories, because that's what you commit to.  You do not commit to sub-tasks.

There is, in fact, a bug in Jira in that the sprint burn-downs do look at hours on sub-tasks.   There's nothing wrong with them doing that specifically, it can be a useful report, but it should not be named "sprint burn down", it should be something more like "sprint hourly throughput". 

[P_]

My reply was not visible, I tried to recreate it here. Now I can see it again,

[P_]

EDIT: First of all, I agree "Sprint burndown" is not an ideal name when it shows the projection of time spent/estimated, but is still extremely useful.

I think we are talking about two different things: estimation for the product owner and team velocity, which is truly done on the story level, but these should really be in story points to represent the relative sizing, putting hours there would beat the purpose of it and that is why it is discouraged by all practitioners I have ever talked to. 

Sub-tasks, on the other hand, are implementation details of stories and there is nothing wrong with estimating them in hours, typically you have to do it so that people assigned can calculate their capacity.

I am not sure what you think is wrong: having a story estimated to be 5 SPs and including e.g 3 sub-tasks, each estimated as 4 hours, is perfectly normal and following the Scrum practices.

I do not think the Sprint burndown has a bug - there is an explicit option to use time estimates and therefore it makes sense you look into the underlying tasks, in the end that is how a hierarachy works. For the same reason I believe there is this option to Include sub-tasks estimates at the Story level, it just makes sense because they represent the breakdown.

Jira does work that way, just this single chart does not. For years we have worked that in companies I do not want to name but I am sure you would know, and it worked perfectly.

[Nic Brough -Adaptavist-]

Ok, I see where your error is.  You think time should accumulate up to Epics.  Not estimates, which is what Scrum works with (of course, time is one thing you could use as an estimate)

You do not burn down on time, you burn down on estimate and completion.  That's why the Epic burn down is not showing you anything - you're asking it to look at something that is not the estimate.

[P_]

Yes, I would expect time to accumulate in epics the same way it does for stories from sub-tasks, nothing more :) 

as Sprint burndown can be set to visualize original and remaining time, I think we reasonably expected the same from the Epic burndown chart (I agree it would be better to call it otherwise, e.g. effort monitoring chart per sprint).

[Nic Brough -Adaptavist-]

But it shouldn't be looking at sub-tasks, because you don't commit to them.  Burndown is looking at what you committed to deliver against what you actually did.

[P_]

I agree (partially) -but  if you commit to a story, you are implicitly commiting to the subtasks it comprises of, obviously. If a story is made up of 3 subtasks, they still represent the story you commited to deliver. But surely the chart should only burn down on completed stories, agreed.

However, as most teams just have to monitor effort (remaining vs spent) for progress tracking, invoicing etc., this view is very useful and probably that is why so many teams use it. And it does look correct - the chart visualizes the remaining and spent effort in hours per sprint, and as stories are made of subtasks, it is indeed correct. We just expected that the Epic burndown would work the same way but I can see its chart is different (bars) so it would not be possible anyway.