That is an interesting point of view regarding software estimation, thanks for that.
Actually, this topic becomes very controversial when you mixed software developers with managers, as it all depends on the point of view. From business perspective, software estimation are basic, from software development a estimation it's just that .. an estimation. So, I would recommend (if you haven't read it yet) "Software Estimation: Demystifying the Black Art" amzn.to/39SiAYW
Because... What is an estimation? What's the difference between an estimation, a commitment or target? Actually, that's the first chapter of the book, and the author provides with an example that most of software engineers have faced at some point: A manager asks for an estimate, when they are really looking for a commitment or a target.
So from my software engineer point of view I agree with your focus, but from companies point of view probably an estimate (or commitment or targtet) is mandatory. Therefore, I think a balance between both trends is mandatory.
I think companies that try to plan too far ahead can't respond quickly and effectively to changing technology and markets. This might or might not impact them.
I think we should focus on prioritisation and delivery over estimation and planning. We don't need to worry about planning if we are sure we are working effectively on the most important thing.
Now you're talking more the language of LEAN agile practices of which I'm engaging with more nowadays. Throw out waste, work on the most important thing, be confident in the next week and less so in following weeks, and go through predictable cycles of planning for things a month out and for this quarter.
Planning anything beyond this quarter will change a ton. Beyond 2 quarters is just business prioritisation/roadmap planning of what to engage in after resources finish up current projects.
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.
Hi Ben,
That is an interesting point of view regarding software estimation, thanks for that.
Actually, this topic becomes very controversial when you mixed software developers with managers, as it all depends on the point of view. From business perspective, software estimation are basic, from software development a estimation it's just that .. an estimation. So, I would recommend (if you haven't read it yet) "Software Estimation: Demystifying the Black Art" amzn.to/39SiAYW
Because... What is an estimation? What's the difference between an estimation, a commitment or target? Actually, that's the first chapter of the book, and the author provides with an example that most of software engineers have faced at some point: A manager asks for an estimate, when they are really looking for a commitment or a target.
So from my software engineer point of view I agree with your focus, but from companies point of view probably an estimate (or commitment or targtet) is mandatory. Therefore, I think a balance between both trends is mandatory.
What do you think? Do you agree?
Very thought provoking! It seems to be that the managers have to be agile trained in order for this to be facilitated smoothly throughout?
// not speaking from experience, never been in a full agile team
Thanks for the feedback.
I think companies that try to plan too far ahead can't respond quickly and effectively to changing technology and markets. This might or might not impact them.
I think we should focus on prioritisation and delivery over estimation and planning. We don't need to worry about planning if we are sure we are working effectively on the most important thing.
Now you're talking more the language of LEAN agile practices of which I'm engaging with more nowadays. Throw out waste, work on the most important thing, be confident in the next week and less so in following weeks, and go through predictable cycles of planning for things a month out and for this quarter.
Planning anything beyond this quarter will change a ton. Beyond 2 quarters is just business prioritisation/roadmap planning of what to engage in after resources finish up current projects.