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; } } }

in progress/done/remaining bubbles vanish once a Sprint is started

Uzi Entin

Hi,

I have a parent task with estimate 0 and 2 sub tasks with 2d estimates. I push this task to a new sprint which is not started yet. On the bottom of the sprint there are these 3 bubbles which show the number of issues (1), the 'Remaining' field (4d) and the 'Estimate' field (0) - So far, so good.

(side note - like many others, I think that Estimate=0 in this case is a design bug).

Once I click on Start sprint, I get these green, yellow and blue bubbles that normally show the accumulated values of 'Not started', 'In Progress' and 'Done'. But in my case all of them are empty. Why?

It works with tasks, but not with sub-tasks. Looks wrong when I do see the overall remaining estimate of the sprint before I start it but not afterwards.

Thanks,

Uzi

Accepted answers

Ubisoft1

Hi Uzi,

Frankly I think that the bubbles for your unstarted sprint are the ones with the bug. Jira Agile will not display the estimates for sub taks, only stories/tasks. It's by design. Atlassian has made it clear that they expect users to be estimating stories/tasks and not sub tasks.

All comments

Ubisoft1

Hi Uzi,

Uzi Entin

Hi,

Thanks for the reply, but this changed since GreenHopper 6.0.3. Please see the following quote from Atlassian Blog (http://blogs.atlassian.com/2012/09/agile-qa-greenhopper-time-estimates-with-sub-tasks/):

Let me start by saying that in GreenHopper 6.0.3 on boards that are configured for ‘Time Tracking” the sum of the remaining estimate for the stories and sub-tasks will be shown in the sprint footer next to the sum of the ‘estimate’ value for the stories. So this will help achieve what you’re looking for here.

So looks to me that this is by design. Yet, it is not clear why the 'remaining' value disappears once the sprint is started. A bit absurd that you cannot see the remaining estimate for a running sprint.

Best,

Uzi

Ubisoft1

I stand corrected. Somewhat.

Key point from the blog you linked is that estimation and tracking are 2 different things, you plan a sprint with estimation and after you start it it becomes tracking:

Why not estimate on sub-tasks and roll that up for Velocity and Commitment?

Many teams break down stories in to sub tasks shortly before the sprint begins so they can use the stories for tracking. This raises the possibility of using the sum of the estimates on the sub-tasks as a way to decide which issues to commit to in the sprint (and potentially for velocity).

As described above, tracking is really a separate process from estimation and velocity. The estimates that are applied to the sub tasks are clearly higher accuracy than those that were originally applied to the story. Using them for velocity would cause the velocity to have both high and low accuracy estimates, making it unusable for looking looking further out in the backlog where stories have only low accuracy estimates. In addition, only items near the top of the top of the backlog are likely to have been broken to tasks, so using task estimates for velocity means that the velocity value could only ever predict the time to complete the backlog up to the last story that has been broken in to tasks.

Using the sub task rollup to decide the sprint commitment would also be dangerous because unlike the velocity value it does not take in to account the overhead of unplanned work or interruptions.

Uzi Entin

As for the article, it is a very interesting theory but in real life I still need the possibility to aggregate sub-tasks estimates. Without this feature, much of Jira-Agile is useless for me.

I would agree, though, that either they show it in unstarted and started sprints or do not show it in both.

Thanks, Uzi

Welcome!

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

Quick Links

Find more posts tagged with

sub-task

remaining-estimate