I really like this write-up, some of the causes are things I had never considered before (I certainly underestimate fatigue when estimating).
I think I'd argue we actually do not need "real time estimates" though. I'm (perhaps foolishly) still a believer in the idea of story point estimation, and the predictive qualities that approach brings. Really what a business wants from estimation is the ability to plan/forecast, and (if done well) abstract story point estimates do that. What happens when people get hung up on "real time" estimates it gets tricky because of things like differences in skill or productivity level. You can have a task that two developers (say one who is very experienced and one who is very new) agree entirely on what work needs to be completed, but it will take the more experienced dev much less time than the less experienced dev. Abstract story point estimates account for this (instead of measuring hours, you're measuring "inherent complexity", and then "on average our team completes X story points every cycle" -- ie team velocity) which still gives that predictability for the business. The problem I've seen is that often teams get hung up on equating story points to units of time, which completely neglects the value of story point estimation. Every job I've had there's been members of the team who fall into this trap (that story points == units of time), and every single time I've seen it lead to poor estimates.
The last section "Lastly, learn from your own estimations" is also excellent advice -- if a task ends up being dramatically more complex than the estimate would have implied, it is so worth the time investment to reflect on why that was.
I enjoy making things to solve problems or just for curiosity's sake. When I am not overthinking things I manage to jot a few posts down which you can find here on devto.
Thank you so much for the feedback and your thoughts on the post!
I like the story point estimation technique and when done properly you do get better estimates especially in terms of complexity and proper pacing. I definitely agree, it doesn't equate to units of time, and to force an equation or a relationship between the two just ends up completely missing the mark.
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.
I really like this write-up, some of the causes are things I had never considered before (I certainly underestimate fatigue when estimating).
I think I'd argue we actually do not need "real time estimates" though. I'm (perhaps foolishly) still a believer in the idea of story point estimation, and the predictive qualities that approach brings. Really what a business wants from estimation is the ability to plan/forecast, and (if done well) abstract story point estimates do that. What happens when people get hung up on "real time" estimates it gets tricky because of things like differences in skill or productivity level. You can have a task that two developers (say one who is very experienced and one who is very new) agree entirely on what work needs to be completed, but it will take the more experienced dev much less time than the less experienced dev. Abstract story point estimates account for this (instead of measuring hours, you're measuring "inherent complexity", and then "on average our team completes X story points every cycle" -- ie team velocity) which still gives that predictability for the business. The problem I've seen is that often teams get hung up on equating story points to units of time, which completely neglects the value of story point estimation. Every job I've had there's been members of the team who fall into this trap (that story points == units of time), and every single time I've seen it lead to poor estimates.
The last section "Lastly, learn from your own estimations" is also excellent advice -- if a task ends up being dramatically more complex than the estimate would have implied, it is so worth the time investment to reflect on why that was.
Great write-up!
Thank you so much for the feedback and your thoughts on the post!
I like the story point estimation technique and when done properly you do get better estimates especially in terms of complexity and proper pacing. I definitely agree, it doesn't equate to units of time, and to force an equation or a relationship between the two just ends up completely missing the mark.