How can I use Subtask hour estimates in the Burndown Report??

Hi All,

I apologize in advance, if this is a question that keeps getting asked. I have researched and see this has been asked, but in earlier versions of JIRA, so hopefully it is resolved in the newest version. 

My company uses three levels: Epic, User Story, Subtasks. 
At the User Story level, we use Story Points. In our case, they are not directly related to hours. The Story Points are a relative measure of Complexity and Effort.

Then below the User Story, the team creates Subtasks under each User Story. These are the tasks that need to be completed for a User Story to be done. And these tasks are estimated by number of hours to complete.

I am looking for a Burndown report that has the total, combined number of hours of subtasks on the Y axis and the days of the Sprint on the X axis.

Team Foundation Server had this feature and it was EXTREMELY helpful.  

Thank you in advance for any suggestions/assistance!

4 answers

Hello,

In your Burndown chart you can change the estimation to "Original Estimate". JIRA automatically sums the extimates/logged time from the children to the parent.

Hi - I'm having the same issue and have tried the above,  Still doesn't work.  I'm not sure what else to try

This function and logic is in place in ALL other major Agile project management software.   Teams update Tasks beneath the Story and EXPECT to see a DAILY BURNDOWN of effort/remaining estimates against original estimates.  THAT is what a Spring Burndown chart is!   Atlassian may not redefine the report for their own convenience.  

If they did NOT offer the Time Tracking option, that might be different, but since they DO it is clear that the TIME logged must be used for Burndown reporting.

This is similar to the Cumulative Flow Diagram only showing Number of Stories.   That is not granular enough for Scrum.   Story Points should be an option on that (posted separately).

When Time Tracking is set Remaining Estimate and Time Spent, the Sprint Burndown chart must show a daily summary of Remaining Time against the Original Estimate ideal burndown line.   Plain and simple.

I echo Paul's sentiment. I'm going to add this to the Jira Team's backlog to be addressed ASAP hopefully.

Some people on here are discussing "hours" for the sprint burndown -- I would offer that in sprint, the burndown is really an assessment tool for the team to see how they are progressing toward their goal - regardless of hours.    With that said, you could also just count the number of subtasks - treating all subtasks as essentially a "1" (the team then needs to realize that subtasks shouldn't ever be longer than 1 day, and if they are - they should be broken down further).

This would mean that the math that JIRA would do would simply be count the number of subtasks needed to be completed for the period of the sprint, and burn down on that.   this works very well, doesn't violate any of the principles of agile AND gives the team the immediate indicator of change.  

Jira can't do this either natively - but scriptrunner can.    You can do this natively in VisualStudio by simply putting a "1" on every subtask. (Visual studio can burn down by subtask hours as well) 

I suggest if you want to burn down subtasks by hours that you use   1/4 day, 1/2 day, full day (2,4,8 for example) as then people aren't trying to determine if it's 2 hours or 3 hours - it makes things go much faster.

1 vote

I am a plus one on this issue. I was an early power user of Jira. Spent many years working in TFS/VSTS. Intent of burndown has always been for view of progress and discussion if the team was on track for their goals. 

This change in Jira is a huge miss. Why muck with it? Allow the sprint burndown to work with hours remaining, just as it did before and other systems support. 

This is what we want and have always practiced.

Sprints burn down when stories you commit to are done.  Not when bits of them are done. 

There's a load of stuff above (and in other conversations) that covers that, as well as explaining that Atlassian have taken the easy route of doing burn down properly by ignoring sub-tasks.

They did it wrong.  Sprints do not burndown by story - projects do.   Atlassian did it wrong.

Like 1 person likes this

No, they didn't.

A project is a collection of Stories (and often other stuff) that needs doing for some reason.  There's usually a good logical reason to group them into a project. 

A Sprint is a time-box, where a team of people commit to completing some Stories.  Often these are drawn from one project, but often, they're drawn from many.

 

Sprints absolutely burn down by story.  They have to so you can measure velocity properly.

Projects also burn down by story, but that's relative to the project, and is not that useful for trying to predict outcomes (and useless for velocity because you can't correct as you go).  Many projects can burn down by story too.  It's useful to know sometimes, but it's a different thing to a Sprint burn down.  Atlassian haven't built for project or project-set burn down.  Not sure why, but I get the sense that they expect us to use other reports to get a better idea of how projects or sets of them are going.

Sprints don't measure velocity.  Velocity is the result of several sprints total effort - also called an "increment".  Velocity of a sprint is a single datapoint and isn't assessed mid sprint.   Sub tasks are to do items that make up a user story.  Knowing the progress of a user story is 100% useful.   The work of a sprint is subtasks to achieve the greater story.  Knowing how subtasks are progressing is critical to rapidly working with the team on potential impediments.   Not having insight into the progress of a " 8" point story or knowing where a 8 point story may have massively increased in effort and needs to be re-assessed and or broken into multiple stories to be refined for future sprints - not having insight into that is foolish.  

You and I won't agree on this one.  yes, Atlassian got it wrong and visual studio got it right.

Wow, that's gone so far through missing the point, it almost makes sense.  But let's go back to the actual point.

I have a story.  I estimate X.  I say I'm going to do it.  Burn down measures completion, which is completely binary.  The sub-tasks are an irrelevance, as they're either all complete (so the story is), or they're not (so the story isn't)

Knowing the progress of a story is useful in other places, and Atlassian ignore that.  But there is no partial in burn-down.

I an new to Atlassian forums but not new to Agile. 

"Sprints burn down when stories you commit to are done.  Not when bits of them are done." - I would have to disagree. I think many other do too:

"The Sprint Burndown Chart makes the work of the Team visible. "

https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog

"A sprint burndown chart shows only one thing: How much work remains."

https://www.mountaingoatsoftware.com/blog/sprint-backlog-sums-all-work-remaining

"The Sprint Burndown Report shows the progress within the Sprint toward reaching the Sprint Goal."

https://www.scrum-institute.org/Sprint_Burndown_Reports.php

"Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that:

  • Remaining work for a Sprint is summed and known on a daily basis.
  • Trending toward completing the work of the Sprint is maintained throughout the Sprint."

https://www.infoq.com/news/2011/07/UpdatedScrumGuide

 

Summary is burn downs are for progress and work remaining. You say "completed stories" but have visibility into many tasks that are being worked on and impact as well as ability base on time remaining is essential and is best when having insight to the sum of the parts. 

For many of us the hours don't matter. It opens up the discussion to the team that there is still work remaining and what it will take to get it done (swarming, more people on more tasks in that story) or not.

There is a whole other discussion when you try to cut story so small to track based on story points, business value simply gets lost. Or lack of progress displaying as stories showing no movement for days in the sprint because they are waiting to complete.

I'm not saying this is the only route, but make it an option.

Like 1 person likes this

"JIRA automatically sums the extimates/logged time from the children to the parent."

It's not true, it counts just the parent items, but we have hour estimates just the subtasks, so it's still a problem.

Yes, it absolutely does sum them up.  You can click on the button to toggle the parent's view between "this issue" and "this issue and sum of all sub-tasks" in the main issue view.

However, that is only done in the issue display, and in the issue navigator when you use the "sigma" fields to display the sums.

Jira Software however, is written to look at estimates on stories, not their sub-tasks.  So you should not expect to estimate and burn-down on sub-tasks.

>So you should not expect to estimate and burn-down on sub-tasks.

 

Then what's the point of having estimates on subtasks at all?  Story sizing is an overall representation of the mass of the work that's being tasked out, not a measure of the weight of each task.   We don't burndown stories, we burndown tasks.  I think the general consensus among the community over the last several year is that the burndown chart is useless for the majority of users. 

That is the point - you should not be estimating on sub-tasks.  Burndown is supposed to be done on stories, when the whole item is delivered, not bits of it  That's part of the reason Atlassian have never implemented anything for sub-tasks.

Nic - If subtasks estimates roll up to the parent to provide an estimate of 40 hours, why would the burndown chart not burndown the total number of logged hours as those hours are also rolled up to the parent?

In theory, I understand your previous message, but not sure I understand the logic.

There's probably a long essay here, and, for what it's worth, I think Atlassian have made a bit of a mess of this one, although it's an "evolved" thing rather than a "we chose to mess it up" thing.

Jira, before "Software" arrived, tracked time.  The time logged on sub-tasks rolled up to the parent and you could (and still can) toggle that display between "all" and "just the parent".

Agile does not work that way.  You commit to doing a story in a sprint, based partly on the estimate for it.  You can break it up as much as you like, but the work done flag is binary - either you succeeded in completing it or you did not.  The various fragments you might have split it up into are irrelevant, what matters is whether what you committed to is done.

This is why they don't appear to work in Scrum, and why Atlassian don't use them in the boards.  Sub-tasks don't matter for estimates.

This needs to be fixed PERIOD and SOON. Or have it as an option. Enterprise teams do not estimate hours across teams at one story (i.e. US), I have QA, Dev, Automation Testing, Integration teams. Each team estimates their portion of the US in subtasks. The estimate of each team is what they are held to. The fact that subtasks do not roll up to total US hours makes no sense. Jira's competitors do this - look at Microsoft VSTS for example.

Like 1 person likes this

If you want a fix, you'll need to come up with a strategy that meets all the different ways of adding up the hours without breaking the basic "deliver or do not, there is no 'try'" principle of Scrum.

Nic: I'm not sure you understand me. This is not a ? of DOD or any of that Scrum mantra. Trust me, I understand what you are saying.

The issue is that multiple tasks (i.e. subtasks) are needed to complete a US across teams. The DOD for US is when all teams work is complete. So if you don't have teams aligned using subtasks - you need to link US to track when the work across teams is complete. Linking does not work because QA does not complete their effort until Dev says is ready to be tested. If you don't group the various team members tasks to a US, managing QA and DEvOps workstreams to a US is a nightmare. Look here for how it's done in VSTS - https://docs.microsoft.com/en-us/vsts/work/scrum/task-board?view=vsts.

I appreciate Jira for it's simplicity and adoption but fail to see why this request is not core to the product. It makes no sense when dealing with a US tied to multiple teams. Is Jira's design saying to flow QA testing into a separate US LINKED to another set of US that has one task assigned to it. That seems to me more work than simply giving an option to sum up subtasks. 

I don't think you've understood what I've said.

Please explain how to code for all the various estimating on sub-task strategies that the Jira user base might use, and how partially done estimates work with the flat "done or not".  Once you can do that, someone can write it.

VSTS adopts one strategy and fails scrum principles immediately.  Jira just dodges the question by ignoring it.

Nic: All I'm asking for is the following assuming using Jira:

- How do I track total hours to complete one US with multiple teams involved in the US. We don't mark a US complete until all tasks(Subtasks as I understand it in Jira) are complete. The burndown chart now does not recognize hours from subtasks supposedly. If so - is the process to let each team member enter the hours at the subtask level and have a scrum master sum the hours at the parent US to make the hours in the burndown work?

- What is the use of subtasks if you don't track hours to a team member. It appears to not provide ownership of hours estimate to the granular level of a subtask that is assigned to one team

Tell me how to use the tool as designed to accomplish the use case. My team can't find links that explain it.

Whether VSTS breaks scrum is open for debate - it depends on how you define the workflow for US DOD. We use both currently and are moving to Jira. I just need my team to understand how to use the tool for what is noted. As you can tell from this thread, I'm not alone in questioning the use case. I appreciate your involvement in the community.

If you want to estimate and do scrum on hours, put them on the story.  It won't work on sub-tasks because it's not built to.

A better approach would be to estimate and burn down on story points on the stories, then put time logs on the sub-tasks (and estimates if you find them useful).

This function and logic is in place in ALL other major Agile project management software.   Teams update Tasks beneath the Story and EXPECT to see a DAILY BURNDOWN of effort/remaining estimates against original estimates.  THAT is what a Spring Burndown chart is!   Atlassian may not redefine the report for their own convenience.  

If they did NOT offer the Time Tracking option, that might be different, but since they DO it is clear that the TIME logged must be used for Burndown reporting.

This is similar to the Cumulative Flow Diagram only showing Number of Stories.   That is not granular enough for Scrum.   Story Points should be an option on that (posted separately).

When Time Tracking is set Remaining Estimate and Time Spent, the Sprint Burndown chart must show a daily summary of Remaining Time against the Original Estimate ideal burndown line.   Plain and simple.

This in JIRA is absolutely wrong.   It's mixed up the idea of what each "measure" is for.  Sub tasks in hours, even if just done in a  1/4, 1/2, full day concept allows for Scrum Masters and the team to quickly make assessments and to shift if need be, determine when to swarm on things, etc.   This same thing allows for the team to see when they've run into a problem and they are no longer on track to achieve what they wish to in the sprint.  This is one more tool that the team can use to communicate.

This isn't for "reporting" it's for the team to assess themselves on a daily basis if need be.  Story points determine different things as user stories and subtasks are indeed, different things.  For teams to truely be self governing they need to have some sort of indicator of where they are in their sprint that they all can agree upon as a basis of understanding.    

Burning down on the user story level isn't useful to a team on a daily basis, where the work actually gets done specific to the goal.    User story burndown also isn't granular enough to adapt quickly.   halfway through a "5" - if the team is stuck, it's important to know this, and subtask burndowns are an excellent indicator of things like this.  

So right now, for example I have a "13" and a "8" and a "5" across multiple developers - so instead of a burndown, I have a "block" that won't reduce itself until one of these is complete.   that is worthless to the team in sprint.   

Again, this isn't about reporting - it's about indication - being able to empirically see something and do something about it accordingly.  

As mentioned - Other tools do this, and do this very well (VisualStudio does an excellent job at some things, others not so much).   why can't Jira?

Like 1 person likes this

But you can't burn-down until something you committed to (the story) is done.  Visual Studio is not useful for Scrum because it's wrong.  Jira avoids the question.

Normally I side with you Nic, in fact I've told peers and clients that "If Nic says it, it's probably true" but I've been working with Agile for a long time now as a coach, a SM, a PO - etc, at various clients - many of whom use Jira.   I've found that Visual Studio works better "in the trenches" on the day to day, but program level reporting out of it is painful.   While, Jira has incredibly good reporting on a portfolio and program level it's working day-to-day is painful, and it needs to do some things that are really well done in Visualstudio.      

The SPRINT burndown as is in JIRA isn't useful as is.  A burndown on a project level makes sense based on story points, velocity, etc.   but the subtasks - the pieces that a team uses to complete user stories, there needs to be some indicator of the movement to the goal.   the burndown in JIRA isn't a burndown, it's "stepped" and in turn misses the key component of a burndown, and that is the ability to rapidly respond as needed (if a team has a velocity of 24 - thinking that an "8" doesn't affect a burndown till it is a "0", is just not operable.)  As I mentioned a burndown, software, etc is only 1 of numerous tools teams can use.   The purist in me says throw it away and do a physical board, but sometimes that's not possible.  

I think part of the issue is what I use the burndown for - which isn't "reporting" - it's an empiric indicator.   honestly it doesn't have to be "hours" - it can be story points, it can be planets, etc.   If the team discusses a subtask and it's a "pluto" and yet it's in work for days - a burndown will show that it needs to be re-examined and see if there are impediments, and shows it fairly quickly.   It's also a great way to convince the various powers that be how empiric Scrum can be - i.e. it has the same information that they want, but it just manifests in a different way.     I've had great success showing burndowns and how there are ways to see into something that seems often to people without form. 

I simply wanted to respond to this as I have a huge amount of respect for how much information you provide to the community, but at the same time I wanted to voice my general disdain with Jira at times.   It seems that Jira wants to be everything and in turn it is a bit mediocre in some areas - I've also seen JIRA used to really undo Agile because of it's flexibility.

Also - sidebar:  I'm really curious as to how you feel Visualstudio fails scrum principles - this isn't a challenge, I'm genuinely curious.   

The scrum guide doesn't mentions burndowns last I checked. My teams would also like to have a burndown per done tasks and see if a task as been in progress for longer then originally planned. As Ryan mentions, it is a tool used by the team for its own planning and assessment. Whatever makes their work more efficient, and things more visible, is OK.

You can easily make one in excel or download one out there.    Because JIRA can't do even a subtask count burndown (all subtasks = "1" and burn down on subtask completion) I use a excel file that I made.   In this, for kicks,  I have 4 burn downs.    Burndown by user story points,  Burndown by subtask points,   burndown by subtask hourly progress, burndown by subtask count.     It shows very quickly to people why burning down on user story points is ineffective and why burning down by subtask hours or count is far more useful to the team to make rapid adjustments in-sprint.

The only point of estimating on subtasks is to have a relative size value AND to get the conversation going in Sprint Planning (if 1 team member thinks it will take some of their morning and another thinks it will take all day - the discrepancy is revealed and discussed), and as I mentioned you can even just treat them all as the same size.

I started with this one, and then made some changes.  For now, this works - but it does have to be maintained manually.   I miss Visual Studio....


   https://www.coria.com/en/insights/blog/project-management/HowToCreateABurndownChartInExcel 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,946 views 19 22
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you