nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Time tracking on sub-tasks

Rahul Aich [Nagra]

HI All

We are stuck in a time tracking issue on jira.

We usually estimate our stories in days and later on the stories are broken down in tens of sub-tasks. Each developers again estimates each of the sub-tasks and logs time on sub-tasks

What it effectively means is that the total estimate gets over-inflated because we are counting the estimate twice (once on parent story and then again on sub-tasks).

Things get even more complicated when you run agile, and due to this the burndown get over-inflated.

What is the possible solution to our problem of double counting of estimates?

Rahul

Accepted answers

All comments

Alexey Skorikov

Hi, I'd like to understand how this should work correctly too.

petry

Hey Rahul,

There are some requests in https://jira.atlassian.com regarding the estimation in subtasks:

Some of them (last two) have some workarounds suggested in the comments, which might be helpful for your case.

Hope it helps!

Cheers,
Andre

Vasu Bangera

Hello,

Any update on this query. Any workaround which we can use for now?

Have the issues been resolved?

Can anyone please provide more information on this.

Regards,

Vasu

Vasu Bangera

Hello, I came to know that this issue persists in all JIRA Instances, can anyone suggest me any workaround that can be followed. Regards, Vasu

Vasu Bangera

Hello, I came to know that this issue persists in all JIRA Instances, can anyone suggest me any workaround that can be followed. Regards, Vasu

Peter Vogel

It's kind of astounding to me that this is still a problem. The closest thing I've seen resembling an answer was a comment in another thread to the effect of, "Atlassian uses the assumptions of Scrum, which means you don't include sub-tasks in estimates. This makes no sense at all to me - we don't all work in pure Scrum environments. Some of us just want a way of quickly showing the totals of all the work involved in an Epic. Atlassian, please pay attention.

Roman Gaufman

Any update on this? - I want the total time estimate to reflect what's in the sub tasks

Hector Gomes

There's some update for this issue?
This is a kind of thing which is surreal do not be fixed yet. I saw requests since 2012.

Mickey Perlstein

Our solution is to remove timetracking on the task and remove original est. in sub tasks, then calculation bleeds through

Lucio Antonio López Prado

One year later and nothing. I really frustrating.

Craig Brunetti_oqw3vn

In multiple companies, our use of JIRA Issues (Story, Task, Bug) includes having SubTasks under each. We run Scrum, so Issues get StoryPoints (not times), and SubTasks get hours (estimates and actuals).

People who are assigned SubTasks, make comments on their work, add assets to their work, and log hours for their work, all in their SubTask. Aggregation should be satisfied by reporting, not process.

Roman Gaufman

We have gotten tired of waiting for this and switched to ClickUp, it has burndown charts, velocity charts, estimate roll-up for subtasks, time-tracking roll-up for subtask (as well as better time tracking) - Jira is still more feature-rich, but we are extremely happy after switching to ClickUp

Robert Giezen

We are also struggeling with this. Why time is not rolled up from subtasks and added to the time of the parent task. We are using next gen assuming its better.

Roshan Milinda

Any update on this?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-administration

time-tracking

burndown