DEV Community

loading...
Cover image for Quick question about time estimation β°πŸ“†

Quick question about time estimation β°πŸ“†

Isaac Torres Michel
・1 min read

Hi everyone, sorry to bother you. I hope you all are having a nice day 😁, just a quick question.

ΒΏHow accurate are you and your teams on your time estimations for your stories?

Lately my team has been failing on our time estimations (about the last 2 sprints), and our PM keeps nagging 🀬 about our performance, but neglecting the complexity of the project (since most of our code base is legacy code, and we find ourselves stumbling once we start working).

So in result, we exceed the estimated time, even with the double of the originally defined time 🀯.

Discussion (4)

Collapse
recursivefaults profile image
Ryan Latta

Hiya,

Estimation is one of those things that never seems to go well but everyone keeps repeating. There's a lot in this topic to get into, but I'll try to give a few little pointers that might help.

1) Have everyone estimate secretly and take the average. Group averages tend to be far better than individuals unless they are a provable "Expert." Try it out one day by bringing in a book nobody is familiar with and have them estimate the number of pages this way.

2) Since you know initial and actuals you can take sample the past 10-20 and create an average that you're off by that the PM can use to pad your estimates.

3) Estimate using ranges. Instead of it being 6 hours, its 6 hours - 3 days. The low is everything going right, the high you want to feel 85% confident in. Wanna figure out how confident you are? How much money are you willing to bet on your range?

4) Drop this BS entirely and ask your PM to start using Monte Carlo simulations to Forecast instead of adding estimates.

5) Right-size work instead of estimating. There is probably a size of work that you all are close to right on. Lots of groups I work with that tends to be a day. Break your work down to that size instead of estimating.

6) You could attempt to use Story Points instead of time, but that usually doesn't work out too much better because someone will try to compare points to time and you'll be in the same boat.

I realize these are short statements, but each are ones I've employed at various clients to help with the stress of estimating.

Collapse
isaactorresmichel profile image
Isaac Torres Michel Author

I can totally relate to your last point. We moved from time-estimation to story points, but.... we're still estimating doing conversion of points-time values.

Collapse
recursivefaults profile image
Ryan Latta

You can also get a little nasty about it and ask the PMs to estimate the ROI, customer satisfaction, or opportunity cost while reminding them that you need them to estimate as accurately as possible since they need to hit their business objectives.

I've done that one before too, a bit bold, but usually helps people realize that certainty in estimates doesn't exactly work, but feedback and prioritization do.

Collapse
yellow1912 profile image
yellow1912

We have the same issue. It's difficult to estimate tasks that you have never done before. You could break it down and try to align the small tasks with similar tasks you have done in the past to make estimation better.

I'm thinking of an adaptive strategy where real duration time can be updated as soon and it is available for each sub task. Given we break the tasks down to proportional task sizes we could re-estimate the whole task pipeline automatically in real time.