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:

1. Sub-tasks tick down the burndown chart as they are completed, or if that's not possible...
2. ...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

[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.

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

[Deleted user]

.

[Maciej Daniluk]

Sorry for digging out the thread.

I get your point, but I don't agree with you, @Nicolas Seronvalle. The burndown chart should be used to track progress of work, and not number of completed items. These are two different metrics, and the latter can be tracked simply by counting items in e.g. "Done" column and putting them against total number of Stories taken into Sprint. 

It's not very helpful to track progress of work in numbers of completed items, and I wouldn't agree that completing 2 out of 6 gives us 1/3rd of work, since the items may be different in size and/or priority or business value they bring. 

What is the value for the Development Team on a daily meeting to see flat burndown on the burndown chart for, let's say 3 out of 5 days? Or see progress every 3 days in 10 workday Sprints? If we could see that some parts of story are delayed, it would tell us that the whole story may also be delayed, which should be brought up to the Product Owner to perhaps help with the blocker or think about rearranging Sprint Backlog with the Development Team (The Owner of Sprint Backlog). 

Also: burndowns in Azure DevOps (former VSTS) track remaining time on sub-tasks level and Story Points on Requirement/Story level. And I think that's how it's supposed to work for agile teams. 

[Bob_Radu]

Completely agree with this.  I'm very sick of people trying to convince users that what they want (repeatedly) isn't what they want.  In my scrum master training the instructor explicitly said "Tracking hours is not worth it, the hours are always wrong and require too much overhead, and tracking the number of issues in the burndown gives you roughly the same shape as hours would" It resonated with me as developers hate estimating and they are horrible at it.  We have been forced to use story points in the burn down which doesn't show if we are making progress at all.  Can't tell on a large story if the developer has sat on his hands for 3 days or is almost done.

[Mark Girie]

SCRUM was originally created for Software and incorporated a concept of a 'potentially releasable product' at the end of every Sprint. There has been widespread adoption of scrum into other areas of development like hardware, embedded systems, mechanical development, etc. In these environments, there is most likely no potentially shippable product at the end of a sprint. Your sprints add up to a finished product, shippable at the end of the development. The whole world isn't doing web, ERP or CSM development ... so we don't 'go live' at the end of every sprint. In this light the current Sprint burndown chart is of no use to us ... its literally a flat-liner for us and we are not able to track progress within the Sprint. 

The very essence of agile is to inspect, adapt and get better. I hope that Atlassian will accommodate this request as I feel it should be a standard option and I wouldn't want to fork out for third-party plugins.

I've raved about Jira and also the reporting capability ... to get my company to migrate to Jira. I have to explain that we are not able to extract meaningful data for our sprint progress information radiators. 

... Is this something that Atlassian would look into?

[Didier de Ghellinck]

The main concept of Scrum is to be time-boxed.  This means that a team has a set of stories (roughly estimated in points) to deal with, and start with a planning meeting, where, based on the Scrum methodology, stories are split in tasks, and tasks are estimated in time (after all, we are discussing Spring planning, don't we?). On all projects I have been running for the last 12 years, I have always asked the developers to express tasks in hours, for several reasons:

• A human body is able to estimate in hours, this is something everyone does.  Estimation in days (not to mention weeks or higher) is much more hazardous.
• If a developer says '3 days' (or '2 points'), in any report they are 'nearly finished', at the end of the first day, the second day, the third day ... and the fourth day.  There is no real tracking at this level.
• The shorter the tasks, the easier it is possible to parallelize work.

So as a rule of thumb, I ask developers, testers, analysis, tech writers, ... (i.e. 'the team') to express tasks in less than 8 hours, otherwise split tasks.

In addition, the fact to have smaller tasks force high level architecture already during sprint planning, and as the whole team attends, everyone is aware of what will be done.

At that moment, the sprint may start, and the purpose is to track progress of the WORK, not the count of stories done.  This is why the per hours burn-down chart is useful:

• Are we going to make it in due time, or is it already time to consider removing some stories
• Things go faster, good, time for PO to select additional stories (and a micro-sprint planning has to take place.

The assumption about 'a sprint deliver shippable product' is not the best definition of a sprint.  A sprint is a commitment from the team to deliver something, with a status 'done' (done is shippable, but also documented, tested, integrated), and the role of the SM is to limit interferences from stakeholders to allow for the team to satisfy their commitment for the duration of the Sprint.  In the meantime, PO may prepare other stories, prioritize them so that they will be ready for planning of the next sprint.

Because teams run planning sessions, the purpose is to track reality vs plan.  This can only be achieved through hours, and as stated above, sub-tasks are a way of tracking hours to know if a story is complete at 100%, 90%, 50%, or not started.  A 'all or nothing' report is totally useless when managing teams.

And may other Scrum products do implement burn-down  charts on tasks, in the way it should be.

So please guys from Atlassian, listen to the experience of Scrum Master, please consider once to provide burn-down charts that allow Scrum Master to anticipate the outcome of sprints, it would be so helpful.

[Deleted user]

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. 

[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

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.

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)

I hope this helps. 

[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. 

[Aleksandr Makarov]

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

[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.