Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How do I get a parent issue to include hours estimates from the sub tasks?

How do I get a parent issue to include hours estimates from the sub tasks? May parent task has 0 hours but the subtasks have original hours estimates. The parent issue should reflect the hours of the subtasks.

6 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

Hi all, this is how I resolved this issue:

Board Settings -> Card layout -> Choose 'Σ Original Estimate' / 'Σ Remaining Estimate'

Hope this will be helpful! 

Screenshot-1.png

Try this...

Guess you have only one sub task in Story. Original estimate of sub task was 5 hrs...someone went in and logged hours as 2 but remaining hours was changed it to 4 (instead of 3).  Now try to see the "Actual remaining hours" using your data . It will never say "4"

This worked for me and was exactly what I wanted. I had only "Remaining estimate", rather than "Σ Remaining estimate", which meant the time estimate of tasks showed up, but not the summary. Once I exchanged them, it worked well. Thank you!

@Erik Sternå,

Good day.

Please can you explain a bit in detail?

Shall I add "Σ Remaining estimate" field on to the Issue screen to view it accumulated?

Thanks in advance.

Regards,

Akbar.

Hi all,

I did it, but the hours don't calculate at the top of Backlog of Sprint

Screenshot_1.jpg

How to fix that?

Yes, that's correct, sub-task estimates are not part of the sprint.

@Nic Brough _Adaptavist_  Thx,

But is it possible to make them the part of sprint? Coz we estimate subtasks not US

No, you do not put sprint estimates on sub-tasks.

With a bit of code, you can report on them as though they are in sprints, and with a lot of code, you can implement a scheme that enables them to be counted as part of a sprint, but it will force you into working in a way that most people struggle with

Thanks.

I just wonder why in Sprint report it puts estimates of subtasks

Ridiculous... why allow Original Estimates to be added to subtask issues if they're not added to the sprint total... and get this .. you can also add subtasks to the Remaining Estimate on the parent task/story card whose estimate IS part of the sprint... but apparently ... "subtask estimates are not part of the sprint" .... I'd love to hear the theory behind that gem of an idea from whatever einstein managed to rationalise it to himself. 

Like # people like this

A sprint is a timebox in which you try to achieve a list of tasks that you have committed to doing (a promise to your product owners).   These items are the stories, issuel-level issues.

If you choose to split stories up into sub-tasks, that's absolutely fine, but it is utterly irrelevant to measuring progress vs commitment.  At the end of the sprint, when you measure your velocity and show what you have delivered, you look at what you managed to do. 

If a story is unstarted, 1% done, or 99% done , so you did not deliver it.  You are not measuring sub-tasks, they are utterly irrelevant.

Hence, the sprint does not look at them, and I over-simplified that down to "sub tasks are not in the sprint".  In reality, they are, but only because they are part of their parent.  Even then, they are not relevant to your estimations or delivery because they are not what you are committing to.

So, don't bother estimating on sub-tasks.  It does not work in Scrum because they're not things you will be measuring.

Like Clyde Trent likes this

Those are some interesting thoughts, and it's sad to hear that Atlassian has such a narrow veiw of working.

I disagree completely that measuring subtasks as part of a story is irrelevant. At the end of a sprint I will find it very helpful for future planning if a story is 1% done or 99% done. Yes, it might be correct that in the eyes of the almighty pure Scrum a task is exactly as completed at 1% and 99%. But at the end of the a sprint, you will start a next sprint, hoping to complete what you didn't the last sprint. To plan this sprint, it's useful to know how far away we are from completing a task. If you have 1 hour or 40 hours left makes a huge difference.

I personally find subtasks an extremely useful way of breaking down and estimating a more complex task. If a task is expected to take 40 hours, it is inherantly going to be a large and complex task, which will be very hard to provide an accurate estimation and tracking of. One natural way to solve this is by using subtasks and track and estimate them, and let the parent task only keep the summary. In a way, it will be an epic, but smaller.

Like # people like this

I don't think there's anything wrong with estimating sub-tasks, but if you're going to do it, you either need to do it outside the scrum process (because they are utterly irrelevant to that), or come up with a scheme that works within it.  

Simply adding them up to the parent is not going to work, unless your process has an absolute rule that your sub-tasks are well defined and all completely estimated before you put their parent into a sprint.

A more flexible scheme would be to have a calculated field on the parent that is used for the scrum estimate, which is calculated from the story estimate minus the estimates on all the sub-tasks.  This gets to be "fun" when the calculated estimate goes negative, there are a number of ways to handle that.

As you can see, both of those schemes are not simple, and you can't do both.  There are other approaches too, of course.  Atlassian have chosen to keep it simple and just not implement any, so estimates on sub-tasks just break.

I really don't see any inherent problem with having a process that requires all sub-tasks to be estimated and well-defined and then having the parent taks summarizing all its subtasks. It will be literally like creating multiple tasks and estimating them, just like you would create regular tasks.

Of course some people might argue that "Then what is the point of subtasks, then?" Given your line of reasoning, I'm starting to question why you even have subtasks in the first place. As I see it, the most normal use-case for sub-tasks is what I presented (You have a task that's not quite an epic, but is still too large to estimate on its own, which is why you estimate it in smaller chunks with subtasks and summarize everything to the parent task). Of course you can use a combination of Epics and Issues for this purpose, but I feel like an Epic is something that's a very large tasks, stretching over multiple sprints. It just gives another level of possible breakdown.

I also don't see any reason at all to work with a pure Scrum process if you feel it doesn't work for your organization. I honestly don't care much about being a purist here, as a lot what's written in Scrum is really not applicable to my work. I think that the tools you use should allow the flexilibity to choose to not work completely in accordance to the scripture.

Like # people like this

Nor do I, it's just a consequence of deciding to put estimates on sub-tasks (and there's nothing to stop you using unsized sub-tasks alongside them)

The sub-tasks are there because when you're working on a story, it can make sense to split it up, sometimes to show dependent steps, sometimes for allocating pieces to more than one person, sometimes just to show it is able to be reduced to neat pieces, sometimes for showing different tech or tasks within it (e.g. this thing is three pieces of javascript, a bit of database work, and we need to have a chat with the system architects about x - 5 subtasks makes some sense there)

And you're right about Scrum too - if it doesn't work for you, then don't do it. (And Scrum has nothing to say about sub-tasks it's all about the story delivery).  Just if you're working with a Scrum tool, don't expect it to support non-Scrum stuff

Like Vishwajeet Chhikara likes this

I feel I have to jump in here, Nic, please accept that there are multiple ways to run scrum. 

For example: 

https://www.scrum.org/resources/effective-sprint-planning

or 

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

both talk about planning sprints to the task level and talk about hours, so comments about hours and sub tasks being 'utterly irrelevant' are misleading at best, and at worst completely wrong.

I find hours are key to monitoring a sprint, story points on the other hand are key for release planning and not a great deal of use in a sprint because they will generally be back loaded. (i.e. completion of stories will happen closer to the end of a sprint, whereas completion of tasks should happen relatively evenly across a sprint)

Like # people like this

I am fully aware that there are many ways to run Scrum.  

That's not what is under discussion here.  Neither are we looking at how you estimate things.

We're looking at the committment you make during a sprint, and the fact that the sub-tasks are part of an item you commit to delivering, not a separate item.  This makes estimates on sub-tasks irrelevant themselves, as they tell you nothing about delivery against commitment.

Like # people like this

But they do, they tell you progress against the story, otherwise the story is simply binary done/not done (i.e. absolutely no measure of progress). So.... not irrelevant.

Not to mention that how you plan a sprint is directly related to how you measure it. Given that the process of sprint planning involves tasks and hours estimates that's exactly what you would use to measure sprint progress...

Like Iulian Onofrei likes this

No.  You've missed the point

Sub tasks can tell you about the progress against the story, they can be used in planning, they can have estimates.  I have said that before.

But, as you've not grasped the context, so I'll repeat it:

At the end of the sprint, when you measure your velocity and show what you have delivered, you look at what you managed to do. 

If a story is unstarted, 1% done, or 99% done, you did not deliver it.  How much of it is done is irrelevant.  And sub-tasks are that irrelevance.

Like # people like this

@Nic Brough _Adaptavist_, and they're irrelevant just because you say so, we get it. But guess what, not everyone thinks as you do! So, from out point of view, your opinions are irrelevant for our workflows, and this is a bug.

No, I'm afraid you have also missed the point about context. 

I am not expressing an opinion here, I am trying to explain why something works in a certain way.  If that way seems wrong to you, then it probably means you don't actually understand what it is for.  There is no bug here, Jira is behaving correctly for the purpose for which it was built.

Like # people like this

@Nic Brough _Adaptavist_ 

if I want to use this structure below in my Product Backlog a cumulation of the subtasks estimates to present them as Stories estimates would be very helpful.

Epic: User Authentication.

User Stories:

  • User Login screen.
  • Forgot Password workflow.
  • Lock account after too many failed attempts.
  • Google login support.
  • Facebook login support.
    • Sub-Tasks/Child Issues:
      • User Login screen:
        • Design login page.
        • Cut SVG icons and images.
        • Implement login page HTML/CSS/JS.
        • Create SQL scripts to create tables.
        • Create SQL scripts for stored procedures.
        • Create web service REST API for user resource.
        • Hook up login page to web service REST API.
      • Forgot Password workflow:
        • ...

Tasks(Engineering):

  • Setup GitHub project repo.
  • Setup GCP (or AWS) account, containers, and services.
    • (There might be Sub-Tasks for these too)
    • ...
  • Setup Jenkins CI pipeline.
  • Design overall (high-level) system architecture.
  • Research and decide on unit test and mocking framework.

Bugs/Defects

I'm afraid saying "I want" with an explanation of your sub-task ideas adds nothing.  It would not be in the slightest bit helpful if it breaks your process.

It does not work that way, you need to have a read through the earlier comments to see why it's like that.

@Nic Brough _Adaptavist_ 

After reading all of this.. You need to stop telling people that they missed your point. They got your point and presented a counter argument. A really good one actually.

Every week we define the sprints for our team for the upcoming 2 weeks. During this sprint we devote ourselfs to complete Feature A,B,C and Bugfix A,B. There are enough reasons why some of these might not be finished like change of your scope (due to high priority bugs for example) or change of your resources (due to sickness for example).

If Feature A and B and Bugfix A is completed then i will adjust the upcoming sprint so it will be realistic again but i won't include Feature A & B nor Bugfix A since they are done.

Let's say Feature C actually is 90% done and is a story that exists out of 10 subtasks. It is estimated on 40 hours and 36 hours has been completed and 9/10 subtasks are completed. We need to move Feature C (out of necassity) to next sprint and reduce our next sprint with 4 hours of works in order to make it realistic again. 

But according to you now you say 'Nope its not done' and you would fill in a whole week for 1 developer in the next sprint (40 hours) just to complete that 10%. 

The way how you describe stories makes subtasks irrelevant indeed. But not in a good way. It does not matter if your subtasks are done? So why give them a status? Why even give them a description, comment field or anything? Why even make subtasks and why not make a list of tasks with checkboxes in the description of the story?

Your arguments make no sense. Please read my answer and pick the points where you want to build your counter argument on. Like how a discussion should be.

And i do not want to see a 'you missed my point' answer. I got your point and i am countering your answer with this one.

Like Iulian Onofrei likes this

It's no good saying "I got your point" if you're just going to post a string of stuff that makes it clear that you have not.

I can't think of another new way to explain it again, I've run out.  I can't understand this for you, I suggest you have another read and think it through again.

I'm not going to try to pick and choose a series of points that have already been countered before.  The answers to all of your points are above already.

@Nic Brough _Adaptavist_ you sound almost as exasperated as I am, so here's a review of your 'explanations', hopefully you'll start to understand other points of view, suffice to say repeatedly saying 'irrelevant' or 'not part of ...' is not explaining...

 

Yes, that's correct, sub-task estimates are not part of the sprint.

But they are, I provided links to prove they are a key part of sprint planning, and are key to measuring progress within a sprint (a key part of the sprint).

 

No, you do not put sprint estimates on sub-tasks.

Yes you do, that's what sprint planning is.... (see my previous comment for links...)

 

If you choose to split stories up into sub-tasks, that's absolutely fine, but it is utterly irrelevant to measuring progress vs commitment.  At the end of the sprint, when you measure your velocity and show what you have delivered, you look at what you managed to do. 

During a sprint they are totally relevant. I accept, looking back at completed sprints (i.e. sprint velocity) you may not be concerned with how 'complete' incomplete stories are, but that's not the topic of this thread. You have decided to limit the scope of this to 'completed sprints' nobody else has (that I can see).

 

So, don't bother estimating on sub-tasks.  It does not work in Scrum because they're not things you will be measuring.

Again, I provided links to the scrum.org and Mountain Goat software that show tasks and time estimates are key to the sprint planning process and key to Scrum, so yes, they do work in scrum (and you measure them during a sprint).

 

I don't think there's anything wrong with estimating sub-tasks, but if you're going to do it, you either need to do it outside the scrum process (because they are utterly irrelevant to that), or come up with a scheme that works within it.  

Not irrelevant, that's what sprint planning is...

 

And you're right about Scrum too - if it doesn't work for you, then don't do it. (And Scrum has nothing to say about sub-tasks it's all about the story delivery).  Just if you're working with a Scrum tool, don't expect it to support non-Scrum stuff

As I've mentioned several times, Scrum has a lot to say about tasks and time estimates, i.e. Sprint planning, burn-down, etc... and yes, scrum is about story delivery, once a sprint is complete, historically, you'll look at story points complete, but planning uses tasks and during a sprint you measure progress using tasks.

 

But, as you've not grasped the context, so I'll repeat it:

At the end of the sprint, when you measure your velocity and show what you have delivered, you look at what you managed to do. 

You decided to talk about 'after a sprint', I don't see anyone else doing that, so this 'context' that you are so concerned about is yours and yours alone.

 

By all means ignore or counter this post, but if you respond it would be nice to have some constructive feedback or counters other than your opinion on how scrum works, perhaps you could even follow your own advice and review the thread... 

 

Oh, and to save some time scrolling, here's the links I provided before:

https://www.scrum.org/resources/effective-sprint-planning

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

Like Iulian Onofrei likes this

Ok, most of that is a waste of time because you're just rehashing arguments against it all again that either show you don't understand the point, and are mostly built off your complete failure to grasp the most important thing I've said

"Yes, that's correct, sub-task estimates are not part of the sprint.

But they are, I provided links to prove they are a key part of sprint planning, and are key to measuring progress within a sprint (a key part of the sprint)."

Yelling "but they are" when they are not, does not help.  Could you please explain how they are, when the sub-tasks are not items you commit to in a sprint?

And yet again your contribution offers nothing...

a) You again say you're right but offer nothing to support that stance

b) accuse me of 'yelling'.. I thought that was all-caps...

c) ask me for explanation even though I have provided links, in fact the start of comment that you have quoted states: 'I provided links...' 

Visit the links, watch the videos, read the text. The following chart is taken from the Mountain Goat link and shows how burndown can be measured during a sprint. The hours remaining is taken from the sum of the tasks on the sprint. Or, to put it another way, the task estimates are being used in the sprint, you could even say they are 'part of' the sprint. It is also how Jira can report current sprint progress.

Also, you seem to be tied to this view that if you didn't commit to it, it doesn't matter. That's a perfectly valid view, but it's still only a view, others are also perfectly valid, that's the beauty of scrum, it can be validly implemented in different ways. 

You're right, I'm exasperated and frustrated that you and others are refusing to understand it, and that makes for grumpy and terse responses.

I've read the links before, they simply confirm everything I've said, or don't mention the subject.

I can't help you understand "estimates are measured against committment, sub-tasks are not committed to (they're just part of their parent) so sub-task estimates are not burned down on"

Until you can show you understand that, it's just not worth expanding on the explanations, you're just wasting my time and yours.  (If you did grasp that, we could explore putting estimates on sub-tasks and making it work in quite a lot of detail, although that has also been discussed above)

@Nic Brough _Adaptavist_ I am going to be straightforward here. As a development agency we live in scrum. It is what we utilize and adjust on a daily basis. We work with a lot of community's and are present on a lot of forums. Never have i ever seen a community leader be so stuburn and also condescending towards community members.

You are threating other people like they are lower then you because you 'the one with all the knowledge' can not be possible wrong.

I am not going to explain my arguments or others arguments again. I did not see 1 counter argument from you on anything i said nor what other people said. You just say they are wrong but not why.

Take a good breath and be open for change and discussion instead of being the stuburn community leader that you currently are.

Even though this is only my second reply i do not feel the need to waste my time posting in this community again. And that is because of how you respond. Take that comment however you want.

Have a nice day

Ok, so the link 'you've read before' that 'don't mention the subject' contains the following:

The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the team to complete.

 

Because they are the people committing to completing the tasks, they must be the people to choose what they are committing to during the Scrum sprint.

 

With the following table(of a sprint backlog):

Screenshot 2021-02-02 at 14.13.09.png

I'm pretty sure all the remaining time estimates are at the story level.

 

And to your comment 'sub-task estimates are not burned down on' that's exactly what was being burned down in the chart from my post you replied to...

 

As for having a discussion, I don't believe you're capable, Jira allows estimates on tasks, Jira reports estimates on tasks both in the kanban view as well as a burndown report (at least), scrum allows for estimates on tasks, sprint planning allows for estimates on tasks, the sprint backlog allows for estimates on tasks. It appears that it's just you that doesn't, and that's fine, if you don't want to use them that's your prerogative, but don't spread mis-information stating that scrum doesn't... 

But note that the commitment is to the Story there. 

Not the tasks.

And that's the point you keep ignoring.  The burn down and committment is done on stories.

So you've now got a scheme where you may want to sum the tasks effort up on to the story so you burn down on it, or you want a full estimate on sub-task scheme, but that's moving into "ways to do estimates on subtasks within the tool", as discussed before. 

Not sure if this has been resolved already but I am running into the same issue.  I have the ff.

- 1 Story with blank estimate

- 2 subtasks underneath with 1 day each

- When I check Version Report, the Story still reflects as unestimated

I was expecting the subtasks are rolled up to the parent which means the parent story is actually estimated.  When both subtasks are closed with 0d left, it should reflect in Version Report (which is not happening).  Is there a way to use the ∑ Original Estimate when creating Version Report?

the same situation

in Backlog view the estimation of subtasks is not included to parent task estimation and total number of hours in sprint - as a result unable to plan sprint based on this number (subtasks not included)

Burndown report does not include subtasks estimate

http://prntscr.com/gyd9co

Questions:

1) how to include subtasks estimate to total parent task estimate so it' counted in Backlog view?

2) how to include subtasks estimate to Burndown report?

Same here. Is there anybody from atlassian helping on this issue?

Please note:

  1. Only time-tracking (effort expended) values roll up to the parent. Estimate (effort projected) values do not (and never will). 
  2. 'Parents' are only Stories or Tasks (or their cloned custom issue types).
  3. Time-tracking values only roll-up to their parent if the 'include-subtask' checkbox is checked in the Time-tracking widget on the 'edit page' of the Story or Task issue.
  4. There is a setting (somewhere) to make the 'include-sub-task' the default for time-tracking for Stories or Tasks... but I can never find it in the docs because the search engine for Jira Documentation is 'optimized' on words like 'roll up' to show only Portfolio issues.
  5. The explanation about why estimates will never 'roll-up' from sub-tasks is that the 'scrum purpose' for estimates and for time-tracking target different aspects of the scrum process (different scrum progress graphs). 
  6. If you are going to comment or inquire about this Jira behavior, please disambiguate your perspective to either 'estimation-only' or 'time-tracking-only' focus so that discussion of these topics can finally become sane and remain sane.

    thanks
Like Kelly Albrecht likes this

I don't understand the thing about estimation. I don't care about scrum graphs or whatnot, I want to see on an issue the sum of the subtasks' estimation time, to know how much will that issue take me to complete.

Like # people like this

You should be able to change the view using Board settings. Ivan posted below with a more detailed response, but essentially set the options via: 

Board Settings -> Card layout -> Choose 'Σ Original Estimate' / 'Σ Remaining Estimate'

This will add either the sum of the Original or Sum of the Remaining estimates to the story tiles

Like Eszter likes this

It doesn't work, because those fields are not shown for issues with subtasks in active sprints.

Like Francesco Sciuto likes this

Also, that feature is kinda wrong because it adds the field to all the tasks, even those without estimation, so you start seeing "None" everywhere.

Odd, within a sprint I can see a summation of the remaining time:

Screenshot 2019-11-22 at 10.19.45.png 

Is this what you're looking to get to?

No.

So, I have a task with 9 sub-tasks, and for example, here is one of the sub-tasks with an 1h time estimate:

Screenshot 2019-11-28 at 12.00.06.png

And this is the task selected, which shows 0m for the time estimate, instead of the sum of its sub-tasks' time estimates, which should have been at least 1h:

Screenshot 2019-11-28 at 12.02.31.png

Like # people like this

Hi Kristi, go to the Time Tracking section of your parent issue and check the box for "Include sub-tasks".

This will aggregate all estimates and logged work from sub-tasks to your parent issue.

I checked the "include sub-tasks" but the hours estimate still shows as blank when planning a sprint as well as the version report. I have my hours estimates in Original Hours Estimate. Should I have it some where else?

Like Don Sharp likes this

That functionality exists as part of the base Time Tracking. I'm unable to paste in a screenshot, but it shows under the three bars (Original Estimate, Logged, Remaining Estimate). I'm not aware of a specific configuration for it. The latest documentation can be found here:

https://confluence.atlassian.com/display/JIRA/Configuring+Time+Tracking#ConfiguringTimeTracking-ConfiguringTimeTrackingSettings

Can you provide any other details that may help?

I want to see the cumulative hours on the parent ticket in the issues list in Plan mode. Currently I only see hours associated with issues that have been specifically assigned an estimate so a parent issue with subtasks will not display an hours estimate when viewing the list.

I´m in the same situation...Is there any solution to this issue?

is this resolved? If so can someone post a screenshot where we do this?

It has never been a problem in plain Jira (Different story if you're using estimates in Software)

All parent issues have a panel where you can toggle the timetracking view between "this issue only" and "this issue and all its subtasks"

Since Jira 3.something, you've been able to use Σ fields in the issue navigator to display the sums in columns too.

Like Marina_Yantsevich likes this

in issues > all issues i can see this.

How can i view this in the backlog? My subtasks times are not updated within the parent

Ah, now you've run into the problems with sub-tasks in Jira Software.  Atlassian are sticking to the way Scrum is done, where estimates on sub-tasks are irrelevant to the backlog and burn-down, and there's no roll-up to parents.

Like # people like this

This seems nuts to me, we don't all work in Scrum. 

Like # people like this

Hey Nic would you be able to elaborate on why Atlassian thinks they are following the Scrum way by not doing this?  Hopefully this can help me understand better why I am struggeling with time registration and ruff burndowns which does not help the team.

Based on the SCrum guide, there is nothing called sub-task ;) of-cause. But what anoys me the most is that Jira does not help the team manage their remaining estimates.

(ref The Scrum guide chapter on Sprint Backlog)

I am use to that the team can easily look at the burndown and see. This is how many hours we estimated for all the sub-tasks left in the sprint, and this is how many hours we have available (- some people are out of the house, doing urgent stuff or sick ) 
And  they they can react if they to low or too high.

But Jira does not help met gather this information in the burndown and as I can understand on your reply, they dont seam to bother about it :(

Like # people like this

Gee, thanks for nothing. There is no "Time Tracking section".

Like Chuck Scammacca likes this

>Hey Nic would you be able to elaborate on why Atlassian thinks they are following the Scrum way by not doing this

In Scrum, an issue is done or it is not.  Partially done does not matter, did you deliver the issue or not?  Estimates on sub-tasks are utterly irrelevant to that question, because it doesn't matter if 0%, 1% or 99% of them are done - the issue is not done.

You burn down when an issue is done.  Not bits of it.

>Gee, thanks for nothing. There is no "Time Tracking section".

Yes there is, if time tracking is enabled and in use in your project.  Have a closer look at the config.

Yes there is, if time tracking is enabled and in use in your project.  Have a closer look at the config.

There's a "Time Tracking" field, but it doesn't have any "Include sub-tasks" option.

Like # people like this

>In Scrum, an issue is done or it is not.  Partially done does not matter, did you deliver >the issue or not?  Estimates on sub-tasks are utterly irrelevant to that question, because >it doesn't matter if 0%, 1% or 99% of them are done - the issue is not done.

>You burn down when an issue is done.  Not bits of it.

Thanks Nic. This explanation does help me understand the Jira approach to burn down charts. I completely agree with the Done or not Done, this is a core definition in scrum and with respect to summing up how many complexity points has been completed (velocity ) this makes perfect sense, but I have not found any definitions aout burndown charts must be based on danoe task only.

My experience as a scrum master is that the team has better use of tracking how many expected work hours is left in the sprint, and compare that to how many work hours is available. Bare in mind the expected work hours are still estimates. They are updated by the team whenever they get wiser and sometimes this may go up some times this may decrease. In both situations the team must consider the consequences and inform the PO if the sprint is on track or will fail. 

@Nic The issue is that the user story is not rolling up the sub task estimations. This is not a function of scrum, it is a function of Jira that seems to not be part of Jira Cloud... 

You can use this field to make sure your sprint capacity is not over or under the mark so you know if you are setting up a  challenge and not a failure.

So to the OP, is there a way to roll up the sub tasks of a story to be seen in said story?

I don't think you've read the conversation properly.

I've been struggling with this for a while as well, and I can't see an 'Include Sub tasks' option. Does anyone know what needs to be done to switch this on?

I think our approach has been detailed elsewhere, but we size stories in story points and when planning our sprint detail the (sub)tasks required for each story and size those in hours.  As a result I'm expecting see a burndown based on story points (at the story level) and remaining time (from the sub-task level). Both are equally valid.

I prefer to show burndown based on remaining time because story points are inherently end-loaded (i.e. dev effort doesn't show until the story has gone through the other stages of test/docs/release/etc...) whereas tasks are not.

As it stands we'll probably stop estimating effort ( in terms of hours) completely as there's no real point. TFS would allow us to do capacity planning so only pull in enough stories to the resource we have (story points don't let you do this), Jira does not. And given that we can't report effort on the burn down, I'm not sure why its there...

Exporting to excel and reporting there is not an option... these tools are to make our lives easier not add extra effort.

on our jira server i see the include subtasks option and we have been using it for years.  we are moving to jira cloud and i can not see this option anywhere.  why are they changing the way jira cloud works from Jira server on something this basic?

 

Has anyone figured this out?

Like Iulian Onofrei likes this

We use jira cloud, and don't see the 'include subtasks' option, but have played around a bit I have arrived on a workable solution.

As mentioned above we size stories with story points and sub tasks with time (generally hours). With an additional bit of effort we can get the burndown I want. That piece is to simply update the time remaining on sub task as it's worked. At the very least, when anyone sets a subtask as done they now set the time remaining to 0. This approach allows me to use the 'Remaining Time Estimate' view of a burndown and we can see progress through a sprint.

All I need to do now is get Jira to automatically set the time remaining to 0 when tasks are set as done (which should be pretty obvious, right?)

 

As an aside, to those on here who seem to think that tracking anything other than story points within a sprint is wrong, I would direct you to Mike Cohn's opinion on the subject (he literally wrote the book on the subject of Scrum) https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog

Essentially, hours is not the wrong way, but nor is story points. I prefer hours/time as I believe it gives a more granular view and you can see potential issues within a sprint sooner.

sum = 0;

for subtask in issue {
    sum += subtask.estimated_time;
}

issue.estimated_time = sum;

Jira, you're welcome! Now go implement it ffs.

Like # people like this

Hey Kristi, check out this question from a while back: https://answers.atlassian.com/questions/28328/jira-and-sub-tasksI believe the discussion in the comments will help clarify things.

The link is defunct.

I also need this. Thanks

Hello,

 

My solution for push-up the Original Estimate of Sub Tasks in parent Task :

  • With plugin : Script Runner
  • Create : Script Listeners
  • Set on these event : Task Update, Task Create
  • /!\Important/!\ Set on user : ScriptRunner Add-on User

 

And Copy & Paste this code :

 

if (!issue.fields.issuetype.subtask) { 
return
}

// Retrieve all the subtasks of this issue's parent


def parentKey = issue.fields.parent.key
def allSubtasks = get("/rest/api/2/search")
.queryString("jql", "parent=${parentKey}")
.queryString("fields", "parent,timeestimate")
.asObject(Map)
.body
.issues as List<Map>
logger.info("Total subtasks for ${parentKey}: ${allSubtasks.size()}")

// Sum the estimates
def estimate = allSubtasks.collect { Map subtask ->
subtask.fields.timeestimate ?: 0
}.sum()
logger.info("Summed estimate: ${estimate}")


// Now update the parent issue
int estimateHours = estimate / 60 / 60

logger.info("Parent Issue: ${parentKey}")
logger.info("Summed estimate in hours: ${estimateHours}")


put("/rest/api/2/issue/${parentKey}")
.queryString("overrideScreenSecurity", true)
.header("Content-Type", "application/json")
.body([
fields: [
timetracking: [
originalEstimate: estimateHours
]
]
])
.asString()

 

That's work ;) 

 

Anthony,

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

TAGS
Community showcase

All you wanted to know about customer support KPIs

When working in customer support, it’s crucial to calculate, analyze and monitor specific numbers, called KPIs (Key Performance Indicators). They go hand-in-hand with customer satisfaction, problem d...

133 views 1 5
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you