Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

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

Roll up sub-task estimates to the story Edited

I found a lot of threads around this, but none helped for Jira-cloud variant, so asking again here.

We recently moved from Jira software to cloud variant. I want to rollup subtask estimates to the story, but it doesn't work. I went to every story and switched on old-view (new view somehow doesn't even show the option), and then enabled 'include sub-tasks'  option. 



It shows rolled up estimate here, but not in the sprint.



How can I achieve this? It would be very cumbersome to estimate both stories and subtasks as well as log work for both.


(Also, before anyone suggests, board settings->card layout is already configured to show summation estimates and remaining time values. It doesn't seem to have any effect in cloud Jira).


1 answer

0 votes

If you are doing scrum, your estimates would not be being placed on sub-tasks.  Jira is pretty strong on doing estimates and velocity according to scrum principles, and scrum has nothing to say about sub-tasks. 

In scrum, you tell your PO and others which stories you are going to try to deliver in a sprint.  At the end of the sprint, you report (burn down, or up) on what you said you would deliver.  If a story is done, you delivered, if it's not, then you didn't. 

Breaking a story up into pieces can be incredibly useful.  But your estimates for scrum are useless on subtasks.  The story is done, or it is not.  It doesn't matter how far through the subtasks you've got - any of them open, you're not done, so you can't burn down (or up).

Does this mean logged work for subtasks also will not roll up to stories? If yes, then what is the point of having 'include sub-tasks' option for stories? 

Yes and no.

There's a long historical story here which I keep meaning to write up as an article so I can point to it. 

The current ending of the story is that time tracking is handled differently by plain Jira and Jira software.

Your first screenshot shows estimates and times rolling up from the sub-tasks into the story.  That's doing what you expect.

However, Scrum (and for that matter Kanban) do not have estimates at sub-task level, as I explained in my answer above.  So you don't get that roll-up in sprints, it's incorrect.

Thanks @Nic Brough _Adaptavist_

I think I get why it is done this way by JIRA, despite so many forums where people are asking for almost the way I was expecting it to work (I saw many of those threads after I posted my question here). 

Here's what I decided to do - Create EPICs and stories for sprints, create subtasks for stories, and then estimate stories (subtasks will come handy in creating the final estimate for the story). Then we would use subtasks to log work against during the sprint. I have added summation used time field to issue screen, so subtasks would roll up logged work hours to the parent story. Given subtasks are still logged work against them, it also helps in the subsequent sprint to see which subtasks took more time, which took less, etc., and helps refine estimate for the subsequent sprint and similar story in the future.  I tested this with test stories, and seem to work well. It's also getting us close to the ideal stage of seeing a story as a logical work unit.

Do not estimate at a sub-task level, it makes your sprint tracking data nonsense, and tells lies to your product owners.  

By all means log a time estimate, and/or log work, but do not try to use that as the board estimate, because it won't work.  Board estimates live at the story level, because that's what you're committing to and measuring.

If you want your Scrum boards to work properly while using time as the estimation data, do not put estimates on the sub-tasks.

Correct. We are estimating stories only, but logging work hours against sub-tasks, which are configured to roll up logged work hours to the parent story. Stories most times have multiple development items (which are mapped to subtasks), and logging work against sub-task (instead of the story itself) helps feature/story owner to see each part/area of the development (which are essentially subtasks) of the story, and see how much time each took. It helps improve story estimation the next time, in the subsequent sprint, at least it is for us so far.


So in short, we are estimating stories but log work against sub-tasks, which then roll up logged hours to the parent story. 

But how does it show in your burndown report? (Original estimate or remaining estimate)

It doesn't.  Sub-task estimates are not used in burndown.  The time (estimated and) logged is not the estimate the burndown is working off.

Suggest an answer

Log in or Sign up to answer
Site Admin

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