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

Question

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

Ask your question here...

Oskar Hanberg · Answer

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.

Nic Brough -Adaptavist- · Answer

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 · Answer

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?