nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Epic Burndown Chart not working - subtasks are ignored

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.

Accepted answers

All comments

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

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.

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-software

jira-software-server

burndown