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; } } }

Including Sub-tasks in Burndown Chart

Chris Bransden

I have seen a few questions on this, but they seem to involve 'story points' which we don't use.

Our sprints are typically made up of a number of parent stories, which are split up into sub-tasks that are given estimates (typically a day or less). The stories normally have no estimate, but that's fine as Jira will total up the sub-task estimates and show that against the parent.

The use of sub-tasks is great for the kind of work we do, which is difficult to isolate into single stand-alone estimable stories. Subtasks can be completed daily, whereas the parent story may last a week, or even the entire sprint.

The problem is, the burndown chart (set to 'original time estimate') only seems to tick down when a parent story is completed. Further, that tick down is represented by a single drop on the day of parent story completion, of the total combined sub-task estimates.

So you can imagine, our burndown charts look like nothing has been done until the final days of the sprint, when the last sub-task of the various stories is completed, and we can close off the entire stories.

What I would prefer is either:

Sub-tasks tick down the burndown chart as they are completed, or if that's not possible...
...when a parent story is completed, rather than ticking down the chart by the combined sub-tasks estimates on the date of parent story completion, it retrospectively ticks down the chart on the dates the sub-tasks were completed.

Are either of these possible in Jira? If not, I sort of wonder what the point of subtasks are, if their completion don't count in the burndown? How can we record the work we do in a way that Jira can understand?

Thanks!

Chris

Accepted answers

All comments

Nicolas Seronvalle

Hi,

In the scrum methodology one of the goals is to give a shippable version at the end of each sprint. It means that every story has to be fully completed before it is considered as "Done". Quality is important so you can't ship a functionality that is 1/2 or 3/4 done. That's what the burndown chart is showing: if a subtask within your story is not complete then you can't ship this functionality then it's like you did nothing.

If you want more visibility on the completion including subtask you can use the "Issue statistic" gadget on your dashboard with "Sprint" as statistic type and including resolved issues.

Otherwise you can also explore some add-ons like Eazy BI , All-In-One reports , ...

Chris Bransden

In the scrum methodology one of the goals is to give a shippable version at the end of each sprint. It means that every story has to be fully completed before it is considered as "Done". Quality is important so you can't ship a functionality that is 1/2 or 3/4 done. That's what the burndown chart is showing: if a subtask within your story is not complete then you can't ship this functionality then it's like you did nothing.

I like this explanation! But what bothers me is that the burndown chart isn't presented in this manner in Jira when you have the Y axis as "Original Time Estimate", which is explained: "Track the total work remaining and project the likelihood of achieving the sprint goal. This helps your team manage its progress and respond accordingly."

By this description, completing subtasks should in fact reduce the "Total Work Remaining" as our "Original Time Estimates" are merely Jira's summation of the sub-task estimates, and therefore I think should be reduced by each sub-task's estimate, every time one is completed. Right?

Nicolas Seronvalle

What you say could make sense but it's not the way burndown charts are used (in Jira or outside of Jira). :-)

If you have 6 stories of equivalent points in your sprint, you completed 2 of them, then you did one third of the work (even if you did 90% of the subtasks of the 4 uncomplete stories). Because your customers will only get 2 stories. Burndown charts show this, what the customers can actually get at the end of the sprint.

If you want other metrics then it's better to use other reports. See my previous comment for some suggestions ;-)

unknown

hongyan999

I totally agree with Maciej on this. I suppose that for the different type burndown chart, the behavior should be different. For the epic burndown, story as the unit in burndown makes sense, since the business owner and team leader are probably the only ones that use it. For sprint burndown, on a day to day basis, task burndown might make more sense. May be it can be shown with a burndown line of different color before the story is completed.

unknown

I am also looking for some solution in JIRA so that burn down chart burns whenever any Sub-Task burn. Anyone here come across this please help.

Request all the people here, who address SCRUM as methodology. First of all, scrum is not a methodology it is a FRAMEWORK. So there is a lot of difference between these two.

Aleksandr Makarov_xqr5i1

Hi, maybe this will help:

https://community.atlassian.com/t5/Jira-questions/Configure-Sprint-Burndown-Chart-to-show-number-of-open-Sub-tasks/qaq-p/1124137#M361720

Danut M _StonikByte_

Hi @Chris Bransden ,

The latest version of our Great Gadgets plugin offers this. The sprint and release burndown gadgets have an option to include sub-tasks, which you could use to achieve this. The plugin is available for both Jira Server (https://marketplace.atlassian.com/apps/1218777/great-gadgets-for-jira-server?hosting=server&tab=overview) & Jira Cloud (https://marketplace.atlassian.com/apps/1216564/great-gadgets-for-jira-cloud?hosting=cloud&tab=overview).

Danut.

Pranshu_Goel

@Danut

Hi,

Thanks for the suggestion looking into subtask burndown and as mentioned Great Gadgets would be able to resolve this for our team.
The team is in the transformation stage from waterfall to scrum - and currently, they are finding difficult to breakdown and complete the stories within the sprint(more work is happening in this area).
One of the suggestion is to start allocating story point to the subtask and burn subtask down. I have a few questions on this:
1) Great Gadget would give me a view of subtask burndown/burn up during the sprint and would it also give me epic burn down including subtask? - and would it take input from the story point field on the subtask or would it require some custom field on subtask in JIRA?

2) Let's say the team would reach to the end of the sprint and some of the stories were finished but some left to finish with some underneath subtasks DONE - how that would impact burndown and what would be the best way to manage in JIRA ( cloning or moving story and would it automatically accommodate on basis of timestamp which subtask were burnt in the previous sprint and which burn in this sprint ? )

It would be really helpful if you reply and help how the great gadget would work.

rcooke

JIRA needs to add this asap. All ways of tracking a Sprint through the burndown should be available to us. I didn't see this in anyone's post - directly from the Scrum Guide.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.

Those are sub-tasks JIRA, and coming into daily scrum and moving a day long sub-task to Done is what we ask of our DEV teams. If not, we know we need adapt. It keeps progress transparent which aids in empiricism.

Not sure why JIRA and Atlassian choices to point us to plug-ins we have to purchase. That's not "how burndowns work in JIRA" is silly. It should be configurable to work however is best for our teams.

Thomas Björklund

I was trying to find a solution for this issue myself, but instead built my own for free using Jira Automations

Three different automations:

1. Sum up sub-task story point value to Parent task Screenshot 2023-04-07 at 15.04.34.png

Use: Smart Value {{issue.subtasks.Story Points.sum}} for the Edit Story Point field

2. Scheduled run of the same thing as 1., catches the sub-tasks that may have been deleted with a story point value.

Screenshot 2023-04-07 at 15.04.52.png

3. When the Sub-task is set to Done, AND the story point field 'is not empty' , clear the Story Point field. (or set the number to 0)

Screenshot 2023-04-07 at 15.05.39.png

I hope this helps.

Erik Santiago _

I agree with you, I use this solution as well.

But there is one thing that really bothers me: in the history table below the burn-down chart, every time a story point decreases, it is labeled as "Scope change" in the event type column, which is not what we mean. Meanwhile, the detail column says that the estimate changed from 16 to 14 (in my case).

Screenshot 2024-05-31 at 00.05.52.png

It's different when you done the story.

I hope Jira can truly provide a burn-down chart for the subtask level.

Welcome!

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

Quick Links

Find more posts tagged with

jira