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

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

VoltaireO

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!

Accepted answers

All comments

Alina Fecheta

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_rspn9r

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

Csaba Schwarczinger_o5m1vm

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

Nic Brough -Adaptavist-

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.

Amy Saxton

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

Nic Brough -Adaptavist-

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.

Paul Berryman

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.

unknown

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

Ryan Finco

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.

unknown

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.

Nic Brough -Adaptavist-

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.

Ryan Finco

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

Nic Brough -Adaptavist-

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.

Ryan Finco

Subtasks aren't the sum of user stories. Subtasks are the "to do" list of the user story. You don't add up your to do tasks and determine if something is done on the basis of their sum.

Also if you are adding up subtasks and you want to get to an epic level via subtasks, I would say you are forecasting using the wrong information.

Andy Johnson_g6zeo6

Not for forecasting but tracking time spent, JIRA has the option in the Epic Burndown to track via Original Time Estimate - does this not total from subtasks?

If not then does this field pull from the Story, and if it does why do Subtasks not total into a Story and then the Epic Burndown pull that from the Story.

Implementation of subtasks in JIRA seems flawed in many ways from a function PoV, or maybe it's JIRA being overly rigid over the intended (required) use of.

It's annoying and I'm not the only person having issues with this.

Ryan Finco

Jira is built from a hour tracking perspective and they then added over time some agile tools. these things didn't necessarily align. but with that said, subtasks have little to do with Epics. and subtasks in hours doesn't "equal" stories in story points - this isn't how team-relative estimation works.

I guess I'm asking why the cascade matters. Why does tracking hours at a subtask level matter here? The team estimates their stories in story points which are a relative value to that specific team, and after a few sprints establishes a velocity. You forecast based on velocity with is a specific empiric value that is relative to the team. Again, why do hours matter at a subtask level if it's really about the work being delivered, and the project-level forecast? I have had great success with using a subtask hour be simply a progress indicator for the team, and that value is essentially relative as well - as I mentioned, you could treat all subtasks as a "1" and still get the progress indication in-sprint. Subtask estimation shouldn't be used in reporting, it's a tool for the team.

Subtasks are seldom the entirety of the story. As I've mentioned before, subtasks really are the "to do" list for the team. Think of this example. If you know this weekend you need to "paint the garage", you will put together a to do list. get dropcloths, buy paint, warn family, etc. if you add up all those "to do" do they equal the garage being painted? I would say 99% of the time they do not. They're in essence starter notes for the tasks ahead. Subtasks are for the team, not for management.

Now, if you aren't using an agile methodologies/frameworks, or are billing hourly I can see the need for hours, but hours as a tracking function within agility and user stories as an agile requirement methodology don't really mesh. A subtask hour roll up doesn't really matter in agile, so what is the problem you are trying to solve? perhaps there is a different way to solve it?

unknown

If you refer to the thread, you'll see why this is needed. Look at my post from LAST May above - May 17, 2018. It amazes me that this functionality is not available - it's a simple ask to tie hours to Sprint Burn-Down - which is an option to choose. But the chart is worthless because the hours entered in subtasks don't roll up. Just make this work PLEASE.

scott.fawcett

Sub-tasks aren't all the same size, so tracking the Work Remaining is important. As a new user to Jira (10+ years with TFS) I have to ask myself of Atlassian even uses their own product. There is so much missing in order to effectively manage a scrum project.

Andy Johnson_g6zeo6

I've given up trying to wrestle with timing and estimation using subtasks as JIRA does a horrible job above the Story level - unlike VSO/TFS and other Agile PM tools.

Our team has pivoted this sprint to estimating entirely using Story Points at the Story level, and are no longer putting any time tracking (estimates and/or actual time spent) at the subtask level anymore.

It's a massive shame that Atlassian has ignored issues with subtasks, that so many have had problems, but for the sake of trying to use JIRA in some way that works they've won.

Oh .. if you do change your workflow to use Story Points, I found today that Tasks cannot have Story Points assigned to them. So that's a thing also.

Ryan Finco

Andy - As I had mentioned, if it's something you really want to have access to - you could do a excel sheet, there would be prep work at the beginning of the sprint, but once that is done a simple daily update could give some transparency. This would be fairly low effort, even lower if you treat all the subtasks as a "1" Also, I do know that you can do a "all subtasks = 1" burndown in JIRA if you use the Scriptrunner plug in. I have the link to how to write it if you need it. basically it just counts the number of subtasks and burns that down over the course of however long the sprint is. it's far more accurate and useful than the native JIRA burndown.

scott.fawcett

Which assumes all tasks are the same size? Frightening and results in a hugely inaccurate burndown. I realize you're just providing a workaround, but even that just goes to show how it's fundamentally missed functionality.

Ryan Finco

It really doesn't at all. I live by the rule that subtasks cannot be more than 1 day, i.e. 8 hours. I've had multiple teams do this successfully for years (30 - 70 sprints). Now, I generally don't advocate STARTING a team with this, it's something to grow into as a team becomes high functioning.

You absolutely can assume all tasks are the same size PROVIDED!!! that you have good refinement and discuss tasks as a team and know what is expected by everyone involved. it also means you do things like "walk the board" in standups, and in general team members are very aware of each other's work.

The only reason why I don't start teams with this idea is because I want the discussion that comes from considering what a task will take. for that i use 2,4,8 (or quarter day, half day, full day as I'll talk about it) The hours on subtasks don't matter in relation to the stories. Once a team is in the habit of discussing subtasks - then the effort alligned to those subtasks doesn't matter.

One thing that i don't like is when subtasks become things like "dev" with no detail - I want subtasks to have some descriptive quality as it's important to see where things are "stuck" as well as when multiple developers want to work on the same story.

I don't draw any parallel from subtask hours to story points. reason being, story points are relative and their accuracy is independent of any hours or values that are put on subtasks. This is key. It's key because the abstract value component means accuracy isn't derived from subtask which makes the hours on subtasks only for in-sprint management. In fact, if you think about it - making story points "more accurate" really means your forecast is LESS accurate because you tampered with the abstraction. A team that does a "54" in a sprint, may have the exact same work that a team that does a "17" in a sprint. the number doesn't matter, what matters is the dynamic between the number over time in realtion to the amount of work. If you make your estimations "More accurate" you create the possibility of changing your velocity VALUE (not the amount of work actually done) - if you change the value, you no longer know what your velocity is and will need to re-baseline.

Dang Thi Thuy Tien

Hi,
You can try with Hierarchical Calculation Field (https://marketplace.atlassian.com/apps/1219833/hierarchical-calculation-field)

Cheers,

Iva_38sihk

Jira does not automatically subtract the logged time from the child to the parent on the Burndown chart. It continues to use the 'Remaining Estimate' field, which is not the same as the 'Remaining Sum' field (which contains the subtraction from children).

Nic Brough -Adaptavist-

Don't put estimates on sub-tasks, it does not make sense and Jira ignores them.

Cagkan Urkmez_9bbe1c

still open and still needed

Erik Thomas

Why can't JIRA just let people use the tool the way they want to and stop trying to enforce some academic's idea of how a burn-down chart should work.

Good software is software that adapts to how customers want it to work. It would be easy enough to allow a configuration in the burn-down chart widget to let us choose which field to use to calculate remaining work? It could be set to Story Points, or Story Original Estimate, or Subtask Estimates.

That would solve every problem I see presented and argued in this thread.

Shame on JIRA for not listening to such a large percentage of their customers and instead forcing their view of how Agile should work.

I have a spreadsheet solution that's the stupidist workaround ever but it does what I need so I can see if a user is on-track or not to complete all their work in a sprint, and we as an Agile team chose to use subtask hours.

At one time Agile was considered a self-directing concept, where teams decide these things, not some draconian software company.

We're an inch from dropping JIRA altogether. It's just stupid.

Danut M _StonikByte_

Hi @VoltaireO & all,

Try our Great Gadgets app. It includes sprint / release burndown chart gadgets that can also calculate by time remaining & time spent. Also, it offers an option to include subtasks.

For more details, please read this blog post.

Don't hesitate to contact support@stonikbyte.com if you have any questions.

Danut

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software