All issues are resolved, but time remaining still shows time?

Bernard O'Flynn August 7, 2011

We've finished a sprint/iteration and all issues assigned to that version have been marked as resolved with 0 time remaining. However the version still shows 1w remaining?

Why is that?

6 answers

1 accepted

3 votes
Answer accepted
Alex Hennecke
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 8, 2011

GreenHopper timeboxes the timetracking statistics between start- and end date of the sprint. Both are GreenHopper specific values. So if work is logged after the end date of a sprint, it won't be taken into consideration for the stats. You could try to backdate a worklog and set the remaining estimate to zero, or correct your sprint end date, because work was still done afterwards.

1 vote
Colin Goudie
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 7, 2011

There must be at least one issue assigned to that version with time on it. You may not see the issue in Greenhopper because of the context's you are using.

I would take a look at the version workload or similar reports for that version in the Project screen, you may find it then. Or use JQL to find all issues for that version with remaining time > 0

Radu Dumitriu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 7, 2011

For sure it's the case. It's the first time I've seen a developer upset because he's having more time to spend :)

Colin Goudie
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 7, 2011

I don't believe the version end date should play a part in that, at least JIRA doesn't. Greenhopper may though.

Can you try run the Version Workload report for that version and see if any time remaining appears?

Bernard O'Flynn August 7, 2011

I did a simple JQL query (project = x and fixVersion = y) and came back with the 6 issues in the iteration. Each of those has no time remaining?

Is it possibly due to the version being over so time calcs aren't updated? The version ended on Fri last.

Bernard O'Flynn August 7, 2011

No time remaining according to that report...?

Colin Goudie
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 7, 2011

It very well could be greenhopper then. TBH I haven't noticed it, but it probably does save the time left at the particular date as it would use that information for the burn down charts etc..

0 votes
Gebsun
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 19, 2015

Log Work Utilities add-on allows to clear remaining estimate on issue close/resolve without a need to modify workflow: https://marketplace.atlassian.com/plugins/com.gebsun.plugins.jira.log-work-utilities/server/overview

0 votes
Alex Taylor
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 29, 2012

Thanks, I'll take a look :-)

Rather oddly, the 4.8d has disappeared this morning. I'm trying to find out if the team went and tinkered with the sprint last night!

0 votes
Alex Hennecke
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 29, 2012

The hour burndown chart offers a tool called Timetracking Analysis which gives detailed information about how the values are calculated, based on the JIRA change history. Maybe that can shed some light on where GreenHopper gets the remaining time value from for your sprint.

0 votes
Alex Taylor
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 28, 2012

We're seeing this as well with GH 5.8.

Our sprint contains 17 issues, each of which is in GH's 'Done' column on the Task-Board and has a zero Remaining Estimate and work-logs dated between the sprint's start- and end-dates. There are no work-logs on the actual end-date.

'Time Estimate' is displayed as 45d, and 'Time Spent' as 33.05d. Both are correct. GH is displaying 'Time Remaining' as 4.8d, however, and I can find no explanation for this.

There are no cards for this sprint which are not being displayed, the Version Workload Report comes back with zero time remaining and to reiterate, no work was logged after the end-date of the sprint. In fact, no changes were made to any of the issues after the end-date.

We are using the built-in 'Default' context to view the Planning-Board and we're looking at it in Version mode. Two of the cards do not have a Resolution at present, but their Original Estimates and Remaining Estimates are all zero, and their work-logs only add up to 1.25d.

Can anyone shed any light on what's going on here?

Suggest an answer

Log in or Sign up to answer