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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.