- I come to think that building software is quite an unpredictable process, as compared to e.g. producing wooden cutting boards. I have never produced a wooden cutting board, but I can image that the time to create one board is more or less similar to creating another board. - In software, the domain is different because we don't know in advance what we need to build. The process is full of surprises and unexpected learnings. That's why estimates in software are hard. - I think a better way to ensure some level of predictability (and focus) is to start asking a different question. Instead of a manager asking "How long will this take?", the delivery team can ask "How much time do we want to invest to this?" - A time-window of six weeks seems particularly intriguing. Quite some things could be delivered in six weeks, even something functional and production ready. But one has to cut features drastically in order to get to scope that can be delivered. - This feature cutting is such an intriguing activity by itself, forcing oneself to think hard about the core essentials. - Something I find myself wondering if this descoping isn't actually the most gripping part of engineering. Further reading: - [Shape Up - Six-week cycles](https://basecamp.com/shapeup/0.3-chapter-01#six-week-cycles) - [[estimates might be waste, the number of stories might be as predictive as estimated story points]] - [My Washing Machine Refreshed My Thinking on Software Effort Estimation — Cosive](https://www.cosive.com/blog/my-washing-machine-refreshed-my-thinking-on-software-effort-estimation) - [Fermi ROI: Fixing the ROI rubric](https://longform.asmartbear.com/roi-rubric/) -