Why does the Remaining Time Estimate not change when adjusting Original Time Estimate?

Question

When setting up my next sprint with tickets in the backlog, if I set an Original Time Estimate (eg 5h) and then decide that it will take 10h, why does the Time Remaining estimate stay at 5h when the Original Time Estimate updates to 10h?

N.B. This happens before I start the sprint.

Brandon Ousey · Answer

Thanks for your response!

So, as far as you're aware, there's no means of adjusting the Time Remaining Estimate on tickets when the Original Time Estimate on those same tickets is changed?

Even when this is done before starting a new sprint?

Nic Brough -Adaptavist- · Answer

Sprints and time estimates are two separate things.

For a sprint, you will be doing that in the context of a board.  The board has an estimation statistic.  In many (most?) cases, that statistic is a simple number in JIra, but it is possible to choose the "time tracking" field as the statistic as well as all the other numbers.

This can be confusing, as the time-tracking field is not a simple object like a number field is, it is a compounded field that tracks the estimate, the work logged against it, and adjustments made.

With a simple number field, you put in a number, then change it later.  This is intuitive for humans, it's what we expect.  With the time-tracking field, you put in your initial estimate, then you log time against it and/or change the remaining time because the estimate changed and/or adjust the original, and/or, and/or...  Whatever the change it, the original estimate part remains, the rest of it is adjusted by your actions.  Scrum looks at the original estimate and what you log against it.

Personally, I've got a good idea how time-tracking works, even with Scrum estimation on top.  It's not good in scrum, it is really very very hard to explain, and, frankly, not that useful in real life.  My recommendation is always "don't use time tracking for your sprint estimation value" (unless you really really do understand the effects).

Go use story points or another more useful and understandable measure.  Even if you decide "an hour" is a useful metric, that's great (just don't try to pretend 1SP = 1H), create a new numeric field for hours and work off that.  Better, use Story points or something like them.