nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

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 🤠

All comments

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 🤠

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.

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

Spencer Hudson

You've hit the nail on the head ... its a new team and new to jira ... and the quality of estimation is patchy so I'm thinking about options to the approach. Acknowledging that some areas will need more refinement than others.

Estimate Confidence :
- High - done before
- Medium - lots of unknowns
- Low - basically a best guess

Providing the confidence will help shape the approach

Spencer Hudson

Great advice ... As context the question of estimation quality came about as a conversation theme between Project Managers and Developers. PM's pushing to get an estimate of any type to start planning and developers caveating their numbers as not enough is know at this point. The sticking point being that some of the estimates are highly accurate ,,, so how do we know the difference.

We had started to think that some "estimate quality" custom variable might be the way to capture the missing context. Reaching out to the community being the way to quickly validate thinking.

Thanks for the reply Bill, and suggestion for additional context.

Spencer Hudson

thanks for your comments , good to know we're not the first people hitting this and better still our thoughts are aligning with what others have done 👍

Bill Sheboy

Thanks for the follow-up information, @Spencer Hudson

In my opinion, there are a couple of challenges with an "estimate quality" value in a separate field: shared understanding of the definition and visibility. (i.e., people may not know about it, and when they do, they disagree on how to quantify it)

I described a common workaround for this scenario: an estimate range as separate fields. Having a range of values can lead to conversations about "why these values", and the range may be used to calculate a single-point value for use in Jira, time-tracking fields. Additionally, keeping the range over time may help people review it when the work completes to improve how they forecast, such as in an agile retrospective or project after-action review.

Spencer Hudson

Thank @Bill Sheboy your follow up reply. I reread you original post and taken together I get where your going with the "estimate range", engagement with the project team and the "can lead to conversations". 100%

i'm wondering if in the short term for new teams, using the "estimation quality" and when the team becomes better skilled we can up the game and then move, if needed to "estimation range". This gives me the immediate visibility.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud