JIRA should not allow one to edit/set the Remaining Estimate on the issue, until some work has been logged on it. I know your motivation for this request, however, I am not sure if we would like to change that behaviour. We need some way to inforce when the Original Estimate and Remaining Estimate can be editted. We are hoping to implement JRA-1351, which will allow you to modify workflow such that all resolved issues (or issues going to a particular status) have the remaining estimate cleared. Will this work for you?

May I ask how you accomplished editing the Remaining Estimate in JIRA 3.7? What screen did you do this on?

Cheers,
Anton

1) Sometimes we reassign tasks to other developers and they think that they will need more or less time to do the work.
2) A general review of the project might highlight over or underestimations (based perhaps on experience of similar work done since the original estimate)
3) On occasion, we use 'place-holder tasks' to represent generic work (integration/system testing) so that we can have accurate estimates for the project as a whole. Afterwards, when this kind of work arises, we like to create specific sub-tasks for that work and put htem under tasks that represent the orginal work done that now needs to be revisited. We do this so that we have a record of where the extra work was, in our report generation. On these occasions I like to 'shave' the estimates from the placeholder task, and add them as the original estimate for the new subtask (note: subtask is not subtask of placeholder task).

At the very least, wouldn't it be possible to create a permission - like the new edit/delete worklogs - so that some project roles could perform this operation (a change to the Remaining Estimate).

In the recent past, we performed this operation through a previous version of the GreenHopper plugin. I dont' know if we would have been able to do this directly through JIRA.

Regards, Brendan.

I am having the same request to have the remaining estimate editable. Currently it is possible to change the original estimate via edit (which I think could be considered as behaviour you potentially don't want). But when work has been logged on an issue, you can only change the remaining estimate via edit.

But there is a simple work around to change the remaining estimate:
1. log work on an issue
2. now delete the work done (in the "Delete worklog" screen you can change the remaining estimate to whatever you like)

Grtz.
Wout

You can work around it in GreenHopper.

• Hide the Team effort curve and estimate accuracy.
• log time spent 1 or whatever you feel like (It will be irrelevant)
• Reestimate your issue

Cheers,

Please see http://forums.atlassian.com/thread.jspa?threadID=20897 This mis-feature certainly reduces the usefulness of JIRA for Agile projects.

With the introduction of the time-tracking data that can includes the issue's sub-tasks in 3.11, there is less to need to log work in the parent issue. However, most high level - initial estimates are usually done without knowing about the subtasks details and should be updated as the subtasks are created.

In fact, the root question since 3.11 is how does the time logging in the subtasks impacts the parent issue ? If we consider a close (composition) link between the parent and the children, any time log in any children should be considered as a time log in the parent as well (2 grain levels of the same work).

Vince

In 3.6.1, it was possible to log work by providing zero as the "Time spent" value. This was perfect for us when we simply wanted to update the "Remaining Estimate" field without logging work done.

Unfortunately, version 3.12 doesn't allow zero time spent values any longer - which is not an improvement in my eyes.

So, I guess simply being able to remove this restriction would solve this issue.

1) It doesn't help you determine when the software is done

2) It is really hard to determine actual time spent. After all do you count time on phone, interruptions on other projects, bathroom breaks, etc. Why make the developers spend time on useless info if it is not needed to ship the product?

3) The time spent on tasks is often used for anti-team purposes like proving developer X worked more hours than developer Y. All that matters in agile is when the team delivers software and when work is done. There is NO benefit to tracking individual performance in agile.

At the very least, I suggest providing plugin writers, such as Jean-Christophe Huet (Greenhopper) a means to circumvent the current constraints.