I can't see an option for "custom field" in time estimation. What am I doing wrong?

[Oskar Hanberg]

This question is in reference to Atlassian Documentation: Configuring estimation and tracking

Ask your question here...

[Nic Brough -Adaptavist-]

Have you created any numeric custom fields for it to work with?

[Oskar Hanberg]

Hi!

No I have not. I thought it meant "any" field. Is there a way I can use "remaining estimate" as an estimation metric instead of "original estimate"?

[Nic Brough -Adaptavist-]

An estimate has to be numeric - I'm not sure how you'd expect a useful estimate to emerge from other types of field (a select list with options of Penguin, Cat and Wombat for example).

Using remaining estimate as an estimation metric would be terribly useless as well - the most simple explanation would be that you'd be double counting everything, or the logged work would cancel it out - all of your charts and reports would be utterly meaningless. The whole point of the estimate is that you say "we think it'll take X", then report on how close you get to X.

[Oskar Hanberg]

OK. Well, how do I properly deal with the following situation?

We have an issue in a sprint that we estimate to 10 hours. In the sprint 11 hours of work is logged, but the issue is not done, and is moved to the next sprint. We re-estimate the issue and set 5 hours on the "remaining" estimate, but since only "original" estimate is counted, it now looks like the issue is done.

I guess what I'm really after is a method of estimation where it counts "remaining estimate at start of sprint", or something like that... Either that or I'm just misunderstanding this whole concept completely. How do you reccomend that issues that are not done by the end of a sprint but has used up all their estimated hours are handled?

[Nic Brough -Adaptavist-]

If you go over your original estimate, then you go over it.  It's an accurate record of what happened.  The issue is not "done" just because you've reached or exceeded the estimate, it's done when you finish it, no matter the amount of work.

I'd recommend simply letting the software record what has happened.  As you've exceeded the estimate, you know your estimate wasn't great, but it's still going to tell you what happened, and help you with your numbers and trends. 

It's perfectly normal to get estimates wrong, but it's worth keeping an eye on the patterns - consistent under or overestimation are something you want to capture and try to amend.  As an example, just using JIRA like this has shown that I'm reasonably good at estimating JIRA related small and medium tasks, but I consistently under-estimate the larger stories.  I'm dreadful at Confluence estimates too, over-estimating almost all of them until there are add-ons involved.  We wouldn't have known any of that if we'd been trying to estimate on "remaining estimate"

[Oskar Hanberg]

While this it true, it makes burndown charts useless, since they will go "flat" on the red line once original estimate on an issue reaches zero. Either way JIRA prides itself on being "flexible" and letting teams work the way they prefer. And there is currently no suitable way to work for teams who prefer to keep the original estimate intact, but still want to re-estimate remaining time on an issue if it ends up taking several sprints to complete.