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

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. 

 

jira1.JPG

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

 

jira2.JPG

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

jira3.JPG

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.

Hi Nic, 

Having the estimates in the story  and having estimate in the subtask ,  

e.g. A story have 2 front-end and back-end task, and story have a original estimate of 2d and sub-tasks have 1d each. team logs time individually to the sub-tasks  

Question - The burnup chart will reflect with the estimated hrs as the team logging time daily ?

No, because, burn only happens on the items you commit to doing.  Sub-tasks are not those items.  Stop trying to do sprint estimates on to your sub-tasks, it's wrong.

Like Seth Tennakoon likes this

Can you point me to a Scrum method article that explains the way of working that you point out? There are a lot of different interpretations out there and (unfortunately) we've been looking at one that breaks down the user stories in subtasks and estimates on the lowest level. I'll be happy to change our approach, but  the method doc would be helpful. 

And, to pick your brain, what would you say is a good practice max-size time estimate for a User Story before you want to start breaking it up, for a 3 developer team running 2 weeks sprints? 

It's more the other way around - it's hard to find a scrum article that talks about sub-tasks at all, they're not what you commit to, so they're not really relevant.

The important bit for Scrum is not that "Jira doesn't do it", it's that if you're going to do scrum estimates, you need to do them on what you commit to.  Exactly how you do that isn't really a scrum thing.  

There are all sorts of ways you could do estimates on sub-tasks and have them roll up, or break down stories into pieces, or even start to think about having sub-tasks be items you do commit to.  The point here is that Jira does not support any of them.  It sees sub-tasks as being component parts of a story, and stories are the things you commit to.

It's fine to break down estimates to sub-tasks, or not.  If you're going to do that, you will need to think about how to actually implement a scheme to support it in Jira given that it sees sub-tasks as component parts.

 

I would start to think about breaking up stories if they're looking like they will consume over half of what you normally expect to achieve in a sprint.  One story sprints kind of miss the point!

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS

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