"When a measure becomes a target, it ceases to be a good measure"
Very well put, and as OP video points out - it stops focus on the real progress. With the whole wheel and engine example from previous post, if the only measure is if engine is overheating, sure, you'll end up somewhere, but you also need to check GPS to make sure you are going to right destination.
One thing I would say about time estimation tho, it could be beneficial if multiple departments are working towards same goal, lets say marketing needs to promote the new feature.
It would be wasteful to complete the feature and only then start figuring out marketing, write their copy etc.
In the end it's always about open and honest communication, specially if it's bad news and "there will be delays".
Nice. I totally agree we will have times we should estimate to coordinate dependencies and ballpark things, but the overall value of the estimate is almost meaningless. It might help you not start building something way out of your budget, but it won’t tell you the real cost since the product has to change.
When the CFO or whoever’s funding the project does so monthly - they know the real cost up front. What they don’t know is the scope. And they don’t need to because the team can try multiple times to satisfy the customer for as long as they’re funded. The work they do has to result in profit, but measured less frequently on milestones agreed upon by everyone as targets. But these are revenue targets (or some other measurable business result) - not targets for a fixed scope of product functionality.
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.
Very well put, and as OP video points out - it stops focus on the real progress. With the whole wheel and engine example from previous post, if the only measure is if engine is overheating, sure, you'll end up somewhere, but you also need to check GPS to make sure you are going to right destination.
One thing I would say about time estimation tho, it could be beneficial if multiple departments are working towards same goal, lets say marketing needs to promote the new feature.
It would be wasteful to complete the feature and only then start figuring out marketing, write their copy etc.
In the end it's always about open and honest communication, specially if it's bad news and "there will be delays".
Nice. I totally agree we will have times we should estimate to coordinate dependencies and ballpark things, but the overall value of the estimate is almost meaningless. It might help you not start building something way out of your budget, but it won’t tell you the real cost since the product has to change.
When the CFO or whoever’s funding the project does so monthly - they know the real cost up front. What they don’t know is the scope. And they don’t need to because the team can try multiple times to satisfy the customer for as long as they’re funded. The work they do has to result in profit, but measured less frequently on milestones agreed upon by everyone as targets. But these are revenue targets (or some other measurable business result) - not targets for a fixed scope of product functionality.