The only way to get better estimates before your your team has started is by having people on the team who've already done work similar to the work you're estimating. The more similar the work they've already done, the more accurate the estimate. This is troubling, because typically doing work that's already been done before isn't valuable.
If you want better estimates it's good to understand what they truly are.
estimate = actual work to deliver - currently understood work yet to be done
As someone progresses on a piece of work, their understanding of the work remaining becomes better, and the amount of work done increases. The perfect estimate is known at the point in time the work is done. Estimates aren't a single number. They're a range which narrows and increases in certainty over time. Any better estimation always amounts - in some way - to doing the work.
I'm going to make an assumption here on what it is you're really asking for, apologies if this is wrong. I think you're really asking "how can I help my team ship work on better understood timelines?" Maybe you could even throw in a "negotiated against business constraints & outcomes?"
Grabbing a single data point up front and never re-evaluating it is a great way to end up with big gaps between the estimate and what actually happens.
The best way (so far) to improve estimation is something we do with aha.io/develop/overview . You have your feature ("what" is to be accomplished). This gets an informed value assigned via a scorecard, vetted & assigned up front by a lead. Work gets carved out into requirements on the feature. For bigger features that might have more questions or work in them, they get a requirement to learn more and build better informed requirements. As understanding advances, the scorecard gets updated. This makes it really easy to both demonstrate & track progress, as well as great for PM's to standardize/compare features apples-to-apples across the project.
Also, full disclosure, I work at Aha!. But many engineers can work a lot of places. So you should actually take this as the vote of confidence it is.
I'm sure, with some finagling, you could replicate the same practice I've described in JIRA. The point is, this constant carving of out of new requirements in the context of a feature drives a lot of conversations. Consistent conversations drive consistent timelines.
When you're carving out requirements, you discuss what the parts are, how they're connected, and the order to do them in. This typically unearths the unknowns. And the unknowns are the single most critical thing to eliminate to increase the accuracy of your estimating.
If what I'm suggesting above isn't feasible where you're at (I've been there - I feel your pain), hiding a little bit of dev work up front in your process (calling them "spikes," "shaping," "research" etc) is the next best way to increase the accuracy of your estimates. I once worked at a place where estimates weren't conversations but commitments carved into stone. A little bit of shaping out features & requirements before our big planning sessions made them so much better. I wish you good luck!
Thank you so much for your helpful comment. You are right, this is my question ->"how can I help my team ship work on better-understood timelines?". Also, your last paragraph is a ray of hope :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The only way to get better estimates before your your team has started is by having people on the team who've already done work similar to the work you're estimating. The more similar the work they've already done, the more accurate the estimate. This is troubling, because typically doing work that's already been done before isn't valuable.
If you want better estimates it's good to understand what they truly are.
estimate = actual work to deliver - currently understood work yet to be done
As someone progresses on a piece of work, their understanding of the work remaining becomes better, and the amount of work done increases. The perfect estimate is known at the point in time the work is done. Estimates aren't a single number. They're a range which narrows and increases in certainty over time. Any better estimation always amounts - in some way - to doing the work.
I'm going to make an assumption here on what it is you're really asking for, apologies if this is wrong. I think you're really asking "how can I help my team ship work on better understood timelines?" Maybe you could even throw in a "negotiated against business constraints & outcomes?"
Grabbing a single data point up front and never re-evaluating it is a great way to end up with big gaps between the estimate and what actually happens.
The best way (so far) to improve estimation is something we do with aha.io/develop/overview . You have your feature ("what" is to be accomplished). This gets an informed value assigned via a scorecard, vetted & assigned up front by a lead. Work gets carved out into requirements on the feature. For bigger features that might have more questions or work in them, they get a requirement to learn more and build better informed requirements. As understanding advances, the scorecard gets updated. This makes it really easy to both demonstrate & track progress, as well as great for PM's to standardize/compare features apples-to-apples across the project.
Also, full disclosure, I work at Aha!. But many engineers can work a lot of places. So you should actually take this as the vote of confidence it is.
I'm sure, with some finagling, you could replicate the same practice I've described in JIRA. The point is, this constant carving of out of new requirements in the context of a feature drives a lot of conversations. Consistent conversations drive consistent timelines.
When you're carving out requirements, you discuss what the parts are, how they're connected, and the order to do them in. This typically unearths the unknowns. And the unknowns are the single most critical thing to eliminate to increase the accuracy of your estimating.
If what I'm suggesting above isn't feasible where you're at (I've been there - I feel your pain), hiding a little bit of dev work up front in your process (calling them "spikes," "shaping," "research" etc) is the next best way to increase the accuracy of your estimates. I once worked at a place where estimates weren't conversations but commitments carved into stone. A little bit of shaping out features & requirements before our big planning sessions made them so much better. I wish you good luck!
Thank you so much for your helpful comment. You are right, this is my question ->"how can I help my team ship work on better-understood timelines?". Also, your last paragraph is a ray of hope :)