Add up estimated times from story's subtasks in scrum sprint

[Flo]

Hi,

we're struggling with this:

If you open any story that has subtask(s) with estimated times, the correct sum is displays on the right side within the story.

But if you add a story to a sprint, there's no sum.

Is this just a setting thing or is this a real issue?

Thanks in advance!

[Nic Brough -Adaptavist- · Accepted solution]

Sub-tasks are not supposed to be estimated in Scrum.  Your product owner ranks stories, and you tell them how much you are committing to.  They have no control (and in theory, no interest) in sub-tasks, the only measure is "is my story done or not?" - Either you've completed the story (under, over or at the estimated level), or you have not.  Having 99% of the work done on a sub-task or spread across many is irrelevant to the Scrum - it's not done until you hit all of them.

There's an essay to be written on exactly why and what you could or could not configure, and how Atlassian have simply dodged the question by doing nothing at all.  But the way to "fix" this is not estimate on sub-tasks, because you don't do that in Scrum.

[Flo]

@Nic Brough -Adaptavist- Thanks for your answer, Nic.

I understand the message, but ... it feels wrong estimating the whole story "again" for the product owner as a developer.
Do you know what I mean?
Let's say, as a developer you add 3 subtasks to a story; each subtask got an estimated time, e.g. 2h for each subtask, means: the story displays 6h (3x2h).
Now the product owner asks a question that has already been answered.

[Flo]

@Nic Brough -Adaptavist- Another issue is: If you have estimated for example those 3 subtasks with each 2h, the story shows altogether 6h.
If you now estimate the story itself (6h), Jira adds these 6h to the other 6h = 12h = 1d 4h, instead of ... 6h.

[Nic Brough -Adaptavist-]

Plain Jira rolls up the estimates and includes worklogs, that's why your issues are able to display a roll up.

But Scrum estimates should not, so scrum related functions do no roll-up.  Your product owner does not care how you do the estimates or what your progress is - a story is either done, or it is not.

[Flo]

@Nic Brough -Adaptavist- Meaning, you don't estimate your subtasks (developer), you only estimate the whole story, so Jira doesn't roll up all the estimates plus the story estimates as a 'workaround'?

What do you mean with 'but scrum estimates should not'? Actually, it does. Or can that be prevented by settings?

Thanks.

Edit:

What I mean is: As a developer you really want to estimate your subtasks. This way the total estimate is calculated automatically by Jira. If you add another subtask Jira modifies the total estimate as well as you change an estimate afterwards.

So this works just fine, but once you want to add a story to scrum board or rather to a sprint... it's not or it's confusing at least...

[Nic Brough -Adaptavist-]

Not a "workaround", but the way Scrum works.  You do not estimate sub-tasks because they are irrelevant to velocity, deliverables and hence burn charts or prioritisation.

This is one of the things people new to Agile don't often understand at first, it can take a while to sink in that your estimates only matter at a story level.

Now, having said that, I believe that people should estimate on sub-tasks, if they feel like it works for them, and the system should cope with it fine.

But there are several ways you could implement "estimate on subtasks" in Jira with or without breaking the Scrum related behaviour, and Atlassian would need to implement options on all of them in order to support all their customers.  Instead of doing that work, they have gone for "don't estimate sub-tasks" as the simplest/cheapest option.

As a random example, I ended up writing a pair of implementations for two teams that worked in the same building on related software.  One did a simple "roll up estimate to parent", the other was a bit more clever and scrum friendly - it subtracted instead, and then rolled up.  (For example, estimate 8 points on a story, then create 3 subtasks of 1, 2 and 3 points - the story now shows 2 SP, each subtask has its own SP, but the total has not actually changed).  There are other strategies, and Atlassian don't want to code for all of them.

[Flo]

@Nic Brough -Adaptavist- I agree with you, but: estimating sub-tasks is helpful for each developer to be better in estimating the whole story ("divide and conquer").

Thank you, Nic.