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!

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

Caroline I'm New Here Jan 25, 2018

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.

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

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?

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.   

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Posted Wednesday in Jira

Join our webinar: How 1B+ feature flag events helped us build the new Jira

Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...

93 views 0 1
Join discussion

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