how do I indicate the quality of my time estimate

[Spencer Hudson]

We're starting out on a new project , with a new team. We have started to estimate our work items ... and we're seeing differences in the ability to provide high quality estimates. 

We know some are really accurate estimates , but others are just a guess.

Is there a way to indicate the quality / veracity of the estimate

what are other people doing?

[Arkadiusz Wroblewski]

Hello @Spencer Hudson 🖐️

Yep  totally normal with a new team. The number alone (hours/points) doesn’t tell you whether it’s a solid estimate or a guess.

The simplest way to handle it in Jira Cloud is to add one small field like Estimate confidence and make it part of refinement.

What I’ve seen work well:

Create a single-select field: Confidence = High / Medium / Low

(High = we’ve done this before, Low = lots of unknowns / basically a guess)

Then use it to drive behavior, not bureaucracy:

Low confidence → do a quick spike/discovery first, or timebox it

Don’t plan the same way for low-confidence items as for high-confidence ones

In retros, look at how many low-confidence items you pulled in.

it’s a good risk indicator

Main idea : separate estimate value from estimate certainty so planning conversations get honest fast.

Please provide us more directed details that we can help You 🤠

[Bill Sheboy]

Hi @Spencer Hudson 

What problem are you trying to solve; "why" do this?  Put another way, what would the team do differently if they had this information right now?

Knowing that may help the community offer better suggestions.  Until we know that...

When asking a question, it helps to provide context.  For example, why your team estimates work items, how they do that, what they do with the estimates, the team's work methods (e.g., agile Scrum, waterfall, etc.), how they manage "new projects", and so on.  Does your organization have a project management team which advises on such practices?  That context may quickly identify things to try.

Generally speaking, when forecasted estimates have uncertainty, it is better to supply a range of values rather than a single value.  Out-of-the-box Jira features do not support estimate ranges.  Thus, teams may mitigate that by several methods:

• select one value, such as from the range maximum, or using a calculation such as "most likely", PERT, etc.
• use custom fields to capture ranges of values and then decide what to use for built-in time tracking's single value
• use marketplace apps / addons for time tracking which support better time tracking features
• use external tools for forecast management, outside of Jira
• etc.

Kind regards,
Bill

[John Funk]

Hey Spencer,

I have seen some people add a custom field to capture the actual effort - call it whatever you want. But when you do your retro, you can go through each card and agree upon what the effort was to actually complete it. 

For example if you have 3 stories that had 5 Story Points each, when you complete the sprint, discuss each one and how much time it took and then update the new custom field. Then you can run reports to compare the value to the Story Points field. (Or T-shirt size or whatever you are using). 

You should only have to do this for a few sprints and you should see the estimates getting closer to the actuals. 

Also, if you are having developers log time to a story, then you could go by that, too.