| TL;DR only estimate the next milestone. Estimates become less useful the further out they are. To get useful info about how long a project will take requires two large changes; careful definition of the problem and effective scoping of deliverables to validate your solution. I push teams to understand the problem before attempting any implementations. Without this context people usually make something awesome that isn't useful. That's another thread on how. The big hack is figuring out what can be delivered to test your assumption quickly. I shoot for about a month of work for this. Give or take. Up front you get the team to agree, "this milestone should be easy to deliver, assuming we understand the problem and our assumptions are right". Then, if you miss that deliverable you stop work on the project and figure out why you were wrong. This stop is meant to combat the Sunk Coat Fallacy. Then you can try a new approach, cancel the project, or keep going having only "wasted" a month. These are called Kill Metrics sometimes. Long term estimates commonly fall to Sunk Cost issues in my experience. This is where a rush hits at the end and you get low quality product. It takes a shift in how engineering communicates with other orgs to pull this off. You need to account for their needs in the milestones and keep them in the loop as a final delivery date comes into focus. It works to go from second half of the year -> Q4 -> Nov -> date. As long as you refine those with enough lead time. |