Roll up sub-task estimates to the story

[Aniket Kulkarni]

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

[Nic Brough -Adaptavist-]

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

[Aniket Kulkarni]

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? 

[Nic Brough -Adaptavist-]

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.

[Aniket Kulkarni]

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.

[Nic Brough -Adaptavist-]

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.

[Aniket Kulkarni]

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. 

[Jarno Kouseband]

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

[Nic Brough -Adaptavist-]

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.

[Seth Tennakoon]

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 ?

[Nic Brough -Adaptavist-]

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.

[Martin Wik Sætre]

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? 

[Nic Brough -Adaptavist-]

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!

[Hector Flores]

Commit to a story??? That doesn't make sense. Commits are associated with work. Work is associated with the logged tasks. A user story in scrum represents the requirements and scope of work, not the actual work. I do not understand this argument. Also, the ask is perfectly valid, why does a story allow for an estimation different than the culmination of the work that needs to be performed to fulfill the requirement of the story. This is completely wrong and I agree with the ask, but my question is why is it not in the base default scheme that comes out of the box. I shouldn't need to "configure" my schemes to be correct.

[Nic Brough -Adaptavist-]

I think you have misunderstood my use of the word "commit".  

When the team selects one or more stories to work on during a sprint, they commit to delivering those stories by the end of the sprint.

And the point of this discussion is that they commit to the stories.  Not bits of stories, but the whole story.  The pieces of it are irrelevant to the commitment - you either deliver what you committed to, or you do not.

[Roshan Milinda]

@Nic Brough -Adaptavist- just out of interest how do you then handle stories where you have back end and front end works to be done by several specialized engineers.

I would like to hear your thoughts on this matter 

Cheers
Roshan

[Nic Brough -Adaptavist-]

Depends on the story and how your people work together.  

If your engineers are in the same (scrum) team, then the team commits to the story and your engineers will talk to each other about the bits each one will pick up.  They may well create sub-tasks just to indicate there are parts for it for different people, but the estimate is still on what you commit to - the main story.

If they're in separate teams, then you split the story up, as it's going to be done in different sprints by different teams.

[Barry, Chad]

Feels like the sub-tasks estimates are being redefined as a different problem and then a justification why Jira doesn't support this new thing tangentially related to the original ask doesn't follow the principles of scrum.

Let's walk through the example with multiple people working on a story.  You're suggesting creating sub-tasks for different people involved in the story and then outside of Jira adding up their estimates to create the story-level estimate.  A process that typically goes something like ... create the sub-tasks in excel so the team can discuss, add up the team's estimates in excel, and then cut & paste sub-tasks into Jira and the total estimate into the story. 

What people are asking, why can't I do that all inside of Jira?  E.g., story level estimate += sum(sub-tasks estimates). 

T-shirt sizing and storying point is still at the story level.

Team is still committing at the story level.

Velocity is still measured at the story level.

Sub-tasks are just a useful tool to help do all the story level stuff.  Jira should be helping, not hindering, the teams using that useful tool.  No scrum principles are being changed, people are asking to take what you say is a normal but currently external to Jira step of scrum planning and wanting to incorporate it into Jira to eliminate that external step.

[Barry, Chad]

Going all the way back to the original response:

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

Sub-taks can be incredibly useful 

I completely agree

Estimates for scrum are useless on subtasks

From your later example, they are used to construct / inform the story level estimate which is a useful function. 

The ask is to maintain that link from the story's estimated, remaining, and logged time back to the sub-tasks used to create those estimates in the first place.  If teams don't find that useful, they can leave sub-tasks at 0 hours which is the default.  If teams do find it useful, let them do it.

So far, I haven't seen any examples of a scrum principle being violated. Nobody said they were committing to a sub-task instead of a story.  Or marking a story done when 1 of N sub-tasks are done.  Those appear to be straw-man arguments irrelevant to the discussion. 

I'm confused why you're making up excuses to prevent teams from self-organizing and finding a slightly modified process that works best for them.  Feels like a far bigger violation of the agile philosophy that underlines scrum and kanban.

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)

This statement is equally applicable to story remaining hours or any other approximation of story completeness.

If the burn down only happens on story done, then it doesn't matter if sub-tasks hold part of the story estimate or not.  On story done, the story's points are burned down or estimated hours (including sub-tasks), etc.

If partial burn down is being reported on an estimated metric, e.g. story remaining hours, then any other estimation of completeness is equally valid until the story is done.  Up to the team to decide which is the best estimate of completeness given their process.

So both scenarios perfectly support time on sub-tasks.

[Nic Brough -Adaptavist-]

So you didn't read read the bit above about implementing a summing strategy, and Jira not doing it because there are many different approaches to it?

And "create the sub-tasks in excel" is incorrect, you should not be doing planning in two places.

[Nic Brough -Adaptavist-]

I think we cross-posted, my last response was to the previous comment.

To answer a couple of points in the last one:

>I'm confused why you're making up excuses to prevent teams from self-organizing and finding a slightly modified process that works best for them. 

I'm not excusing anything, you seem to have not read the parts about "if you want to do it, you will need to think about it".  I have been explaining why Jira works this way and why Atlassian have not inflicted one fixed way of doing it on everyone.

>Feels like a far bigger violation of the agile philosophy that underlines scrum and kanban.

Um, Scrum and Kanban existed before the Agile manifesto was written, it's more a case that they are a good fit for being Agile, not Agile underlying them.

And surely it's Agile for a Scrum tool to support Scrum in full, and enable you to implement your chosen scheme for using it to do not-quite-scrum

>If the burn down only happens on story done, then it doesn't matter if sub-tasks hold part of the story estimate or not.  

Absolutely correct.  That's why Jira Software's boards ignore the estimates on sub-tasks.

[Barry, Chad]

And surely it's Agile for a Scrum tool to support Scrum in full, and enable you to implement your chosen scheme for using it to do not-quite-scrum

The point of my feedback is that claiming estimates on sub-task is "not-quite-scrum" is a misrepresentation.  The ask is for Jira to change how it calculates a story's hours to make it easier for teams.

Current: Story Original Estimate = Ticket's Original Estimate

Change: Story Original Estimate = Ticket's Original Estimate + sum(sub-task original estimate).

You're advocating you can add up the sub-task hours yourself and then enter them on the story's ticket.

We're asking why can't Jira do that for us?

We're NOT saying we're going to commit to a sub-task instead of a story.

We're NOT saying we're going to mark a story as done just because a sub-task is done.

We're NOT advocating any change to burn-down calculations other than the more flexible calculation of the story's original estimate.

Honestly, I suspect this is really a limitation of Jira not really having the concept of a computed field so including the sub-task estimates in the story is hard.  All this "not true scrum" is just trying to claim it as a feature instead of a won't do.

And "create the sub-tasks in excel" is incorrect, you should not be doing planning in two places.

Exactly!  And we would like to do that planning in Jira.   Maybe you're good adding a bunch of numbers in your head but I typically do it in a tool like Excel.  I would prefer Jira did it for me and not force me to use another tool.

So you didn't read read the bit above about implementing a summing strategy, and Jira not doing it because there are many different approaches to it?

Oh, I read it but maybe I'm missing some aspect if your explanation.  There appears to be 2 strategies being discussed.  Story is the sole container of estimates (Jira way) vs sub-tasks can also contribute to the story's estimate (the ask from Jira customers).  What are many other strategies you're worried about?

I have been explaining why Jira works this way and why Atlassian have not inflicted one fixed way of doing it on everyone.

The point people have been making is that Jira IS inflicting one fixed way of doing it on everyone.  People have been requesting a second way and the excuse given why Jira doesn't do it that way is because it violates scrum principles.  I'm saying the examples of the principles being violated so far appear to be strawmen.

Um, Scrum and Kanban existed before the Agile manifesto was written, it's more a case that they are a good fit for being Agile, not Agile underlying them.

Good point, I would have been more accurate if I had written "that is shared with" instead of "underlines".  The original 1986 scrum paper included the principles of self-organizing teams and iterative process improvement which is the point I was making.  We're asking Jira to support working how the team wants to work based on feedback of pain points with Jira's current workflow.

Absolutely correct.  That's why Jira Software's boards ignore the estimates on sub-tasks.

Feels like you missed the point of the paragraph.

Since you advocate burn-down only happens on story done, by your logic all estimated completeness reports such as remaining hours should be removed from Jira.  If you're ok with some approximation of story completeness then sub-tasks are just as valid as the others.

Conversely, if burn-down is all or nothing at the story level then defining a story's "original estimate" as ticket original estimate + sum(sub-task original estimate) introduces no change to scrum philosophy and is simply a tool being flexible.

[Barry, Chad]

And surely it's Agile for a Scrum tool to support Scrum in full, and enable you to implement your chosen scheme for using it to do not-quite-scrum

The point of my feedback is that claiming estimates on sub-task is "not-quite-scrum" is a misrepresentation.  The ask is for Jira to change how it calculates a story's hours to make it easier for teams.

Current: Story Original Estimate / Remaining Estimate = Ticket's Original Estimate / Remaining Estimate.

Change: Story Original Estimate = Ticket Original Estimate + sum(sub-task original estimate).

You're saying we should add up the sub-task hours ourselves and then enter them on the story's ticket.

We're asking why can't Jira do that for us?

We're NOT asking to commit to sub-tasks.

We're NOT asking to say a story is done when a sub-task completes.

We're NOT asking for burn-downs to change other than to use the more flexible calculation of the story's original estimate. 

And "create the sub-tasks in excel" is incorrect, you should not be doing planning in two places.

Exactly!  And we would like to do that planning in Jira.  Part of planning is almost always breaking a story into sub-tasks, thinking about how many hours each of those sub-tasks will take, adding up those hours, and then using that total + additional hours for the overall story.

I'm terrible at adding a bunch of numbers in my head so I typically use Excel.  I would prefer Jira did it for me and not have to use another tool.

So you didn't read read the bit above about implementing a summing strategy, and Jira not doing it because there are many different approaches to it?

I read it but maybe I'm missing some aspect if your explanation.  There appears to be 2 strategies being discussed.  Story is the sole container of estimates (Jira way) vs sub-tasks can also contribute to the story's estimate (the ask from Jira customers).  What are many other strategies you're worried about?

I have been explaining why Jira works this way and why Atlassian have not inflicted one fixed way of doing it on everyone.

The point people have been making is that Jira IS inflicting one fixed way of doing it on everyone.  People have been requesting a second way and the excuse given why Jira doesn't support is because it violates scrum principles.

Um, Scrum and Kanban existed before the Agile manifesto was written, it's more a case that they are a good fit for being Agile, not Agile underlying them.

Good point, I would have been more accurate if I had written "that are shared with" instead of "underlines".  The original 1986 scrum paper included the principles of self-organizing teams and iterative process improvement which are the principles being invoked.

[Nic Brough -Adaptavist-]

>The point of my feedback is that claiming estimates on sub-task is "not-quite-scrum" is a misrepresentation. 

How?  Scrum doesn't even mention sub-tasks of any shape, it looks at sprint items alone.

Which sub-tasks may be part of, but are not sprint items themselves.

>The ask is for Jira to change how it calculates a story's hours to make it easier for teams.

Yep, I'm 100% with you there.  Jira does it in the most simple way, it expects us to put the estimate on the story.  And doesn't do anything with sub-tasks.

>You're saying we should add up the sub-task hours ourselves and then enter them on the story's ticket.

>We're asking why can't Jira do that for us?

No.  I'm pointing out that a simple "add up the hours on sub-tasks" is a perfectly valid option, but that it's not the only way to handle estimates on sub-tasks. 

The easiest way to handle estimates on sub-tasks is "don't".  Adding them up to the parent is one very good way to do it, but it tends to push you away from doing scrum, and is a bit over-simplified - People who do it usually move away from it quite quickly, or stop being Agile.  There are quite a number of other ways of doing it, with varying levels of success (the best one I've seen work well is subtractive, not additive) 

>We're NOT asking to commit to sub-tasks.

Nope, I know that, but you are asking to commit to their estimates without considering the parent

>We're NOT asking to say a story is done when a sub-task completes.

Yes, you're not asking for that, and Jira already works here.

>We're NOT asking for burn-downs to change other than to use the more flexible calculation of the story's original estimate. 

Ok, so you're asking for the burn-down to use the estimates on stories.  It does that.

>There appears to be 2 strategies being discussed.  Story is the sole container of estimates (Jira way) vs sub-tasks can also contribute to the story's estimate (the ask from Jira customers).  What are many other strategies you're worried about?

The strategies are all about how you create estimates.  I'm not "worried" about any of the strategies people might use,  My point is that you need a useful one that works for you, and then you need to work out how to implement it in a system that lets you (rather than one that inflicts over-simplified ones that don't work)

>The point people have been making is that Jira IS inflicting one fixed way of doing it on everyone.  People have been requesting a second way and the excuse given why Jira doesn't support is because it violates scrum principles.

No.  You have not read or understood any of what has been said before about how it does not support not-scrum.  Jira doesn't inflict anything on you, it just supports the most simple case, and doesn't have any easy ways to do any of the more complex ways of doing it.  More recent versions of Jira enable us to do it without needing to add apps for it, but it still requires a bit of thought.

>Um, Scrum and Kanban existed before the Agile manifesto was written, it's more a case that they are a good fit for being Agile, not Agile underlying them.

>Good point, I would have been more accurate if I had written "that are shared with" instead of "underlines".  The original 1986 scrum paper included the principles of self-organizing teams and iterative process improvement which are the principles being invoked.

Yes, I was being a bit pernickety there, I've worked with three of the authors (one of them is now an Adaptavist), but it was the first one I met who pointed out that Scrum pre-dated their work.  And also that sub-tasks are not sprint items.

[Barry, Chad]

> How?  Scrum doesn't even mention sub-tasks of any shape, it looks at sprint items alone.

Breaking stories into tasks is often mentioned as part of sprint iteration planning..  Some guides warn about it not becoming the focus but still recognize it as an optional but commonly used tool.

Some teams break each story into tasks. As the tasks are identified, team members discuss each one: who would be the best person(s) to accomplish it, approximately how long it will take (typically in hours), and any dependencies it may have on other tasks or stories

-- SAFe Guide

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.

-- 2020 Scrum Guide

[Barry, Chad]

Adding them up to the parent is one very good way to do it, but it tends to push you away from doing scrum, and is a bit over-simplified - People who do it usually move away from it quite quickly, or stop being Agile

That is a pretty big leap and I would love to see the studies backing up that claim.  I've found it to be a common practice across teams and companies  that have successfully used scrum for years.

I understand the sentiment, focus on the goals and outcomes and not get bogged down in a detailed plan.  Creating sub-tasks as part of the sprint planning can be taken to extremes but that's true for everything so not really a valid reason to say don't do it at all.  If a team finds it helpful, most scrum guides I've read would say keep doing it.  If the team finds it doesn't need it, then don't.

the best one I've seen work well is subtractive, not additive

I'm not sure I understand what you mean.  My guess is start with the total estimate for the story and then subtract sub-tasks.  If you end up significantly negative or positive, discuss why there is a discrepancy?

And also that sub-tasks are not sprint items

You keep saying "not sprint items" but I'm not sure why that is important. 

Sub-tasks are not required to execute a sprint but as many "official" scrum guides point out they are common and helpful.  It is also implying that Jira should only support some list of officially sanctioned scrum items.  Jira already deeply supports sub-tasks and has a sprint board mode that makes them the focus of the daily stand-up.  Are you suggesting Jira features or fields that are "not a sprint item" should be removed?  Of course you're not, so using "not a sprint item" is a weak reason not to add a feature.

Nope, I know that, but you are asking to commit to their estimates without considering the parent

Not sure why you think that.  Rollup would include any estimate on the story itself + estimates on the sub-tasks.  So if the story has hours not associated with a sub-task it would still be part of the consideration.

Jira doesn't inflict anything on you, it just supports the most simple case, and doesn't have any easy ways to do any of the more complex ways of doing it

Guess it is matter of semantics.  A lot of people requesting a feature and then being told no because they're doing scrum wrong feels like it is being inflicted.

More recent versions of Jira enable us to do it without needing to add apps for it, but it still requires a bit of thought.

Cool, can you point me to docs for the new feature so I can get the roll up behavior our team would like?  Bonus points if all the built in Jira widgets that show story hours can be switched to show this new value,.

[Nic Brough -Adaptavist-]

So that's a very long post on just how not to be agile or do scrum while pretending to, so rather than an essay and diving into detail, I'll try to get down to the root of your misunderstandings.

>Breaking stories into tasks is often mentioned as part of sprint iteration planning..  Some guides warn about it not becoming the focus but still recognize it as an optional but commonly used tool.

You should have emphasised, "warn about it not becoming the focus".   That is exactly the point - sub-tasks in Jira do not carry estimates because they are not the focus

>You keep saying "not sprint items" but I'm not sure why that is important. 

That is the whole point of the conversation.  When you estimate and execute a sprint, you do it on the stories that you bring into the sprint.  Sub-tasks give you a way to do all sorts of ways of breaking up the story for analysis, allocation, development and so-on, but they are just a piece of a story.  You commit to dealing with your stories, not bits of them.

>Guess it is matter of semantics.  A lot of people requesting a feature and then being told no because they're doing scrum wrong feels like it is being inflicted.

No, it's not semantics.  It is very clear.  Jira is not inflicting anything on you, it's just not implementing any of the many ways you could do estimates on sub-tasks.  

[Barry, Chad]

I get it, you believe it is an anti-pattern for scrum.  I agree that it can be bad if taken to the extreme but I've also seen it be a useful tool if not abused.  The issue is that you keep making assertions about how we are using sub-tasks that are not accurate.

For example, I've tried to express in multiple ways that "adding estimates to sub-tasks  DOES NOT mean it is pulling focus from the story in our scrum process".  Your response is "sub-tasks in Jira do not carry estimates because they are not the focus".  I'm agreeing that sub-tasks should not be the focus.  I'm disagreeing that adding estimates to them makes them the focus. Hopefully you can see the difference and why I feel your answers have failed to address the main point of disagreement.

I think we all agree that breaking a story into sub-task can be a useful step to better understand the story and inform the story's estimate.   I'm asking for Jira to provide some tools to make it easier to roll that learning back into the story.   You're saying that is impossible because there are lots of ways teams might do that (so far 3 have been expressed). Seems like you're not against this part of the process, just that you think it is a hard problem for Jira.

[Nic Brough -Adaptavist-]

You say 

"I get it, you believe it is an anti-pattern for scrum. "

No.  You have not read what I wrote before about sub-task estimates working fine for scrum.