One problem with software estimation; it is deployed by default, an assumed part of the development process. A way to challenge such defaults is to get specific on what problem we are trying to solve.
This article reminds me of how important it is to have a Decision Tracking system, and to go back to it every time a decision seems obsolete (like being obsessed with software estimation).
Yes that can be a handy tactic. Even just being explicit about what our hypotheses are and what might be evidence for or against whether you are making progress. The pace of learning is such a critical part of most software development.
This post describes a form of planning poker focused on value rather than effort. Probably a point that I have implied but could say explicitly - if the world put as much time estimating value as it did effort we'd likely be better off: https://medium.com/@allankellynet/benefits-of-value-poker-2-of-2-f3cf3ca71609
This article reminds me of how important it is to have a Decision Tracking system, and to go back to it every time a decision seems obsolete (like being obsessed with software estimation).
Yes that can be a handy tactic. Even just being explicit about what our hypotheses are and what might be evidence for or against whether you are making progress. The pace of learning is such a critical part of most software development.
This post describes a form of planning poker focused on value rather than effort. Probably a point that I have implied but could say explicitly - if the world put as much time estimating value as it did effort we'd likely be better off: https://medium.com/@allankellynet/benefits-of-value-poker-2-of-2-f3cf3ca71609