This approach isn't quite right. There are some good explanations by other community members. Instead of repeating it, I'll copy and paste the same here (along with the links of the source article in case you want to reference them).
Source: Click here
Comment by: Nic Brough _Adaptavist_
we should look at estimates in two ways.
There are issue-estimates and sprint-estimates in play here. The issue-estimates are doing what you expect - they're literally an estimate for the current issue (and there's a display of the sum of an issue estimate and all its sub-tasks if you want)
The problem here is with the sprint-estimate. A sprint is a time-box, into which you throw a load of stories (issues) that you commit to achieving inside that sprint. The sprint-estimate is the estimate for the whole sprint. The trick here is to understand that a sub-task is not something you commit to when you're building a sprint. You commit to their parent issue (and hence automatically all the contained sub-tasks if you have any). The sub-tasks are irrelevant when looking at the commitment.
Now, there are a lot of schemes you could try to use for having sub-task estimates, but in off-the-shelf sprint process, they're irrelevant. Atlassian have not tried to build any support for the various sub-task roll-up in sprint schemes, they've simply gone with plain Scrum, where estimates are only for commitments.
So, most of Jira will happily look at your sub-tasks (and their numbers), but the sprint-related stuff (backlog, board, velocity etc) will not, because sub-tasks are not commitable items.
----
Let's say you put in:
- Story 4 hours
- Sub-task A: 2h
- Sub-task B: 1h
Here, your sprint estimate is 4 hours, because Jira does not look at sub-tasks. But the time that non-sprint functions look at is 7 Hours when you're counting roll-ups.
If you then implement "add up sub-task estimates to parent", you end up with a story that says 7h, burns down correctly, but you've actually got estimates of 10 hours because you're now double-accounting the sub-tasks.
Neither of those ways work consistently in Jira. The best option is to not estimate sub-tasks.
Source: Click here
Comment by: Nic Brough _Adaptavist_
You should not be putting sprint estimates on sub-tasks. In a sprint, you pick some issues and commit to (trying to) deliver them at the end of the sprint. You do not commit to doing bits of stories. Sub-tasks in Jira are entirely a piece of a story, they are not individual items. So the sprint estimate on a sub-task is utterly useless in itself, your sprint is measured by the stories it delivers, not bits of them.
In reality, there's no problem putting estimates on sub-tasks, it can be very useful (especially in planning, because sizing fragments of a story is usually easier than trying to estimate the whole unknown). But if you're going to do that, you need to think of how the estimates should roll up into the parent, because only the parent is the deliverable and measurable thing.
TLDR: If you are determined to put sprint estimates on sub-tasks, you are going to need to do some scripting or automation that can do the roll-up for you. The most simple solution is just do Scrum properly, which means not estimating sub-tasks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.