Architecture-Driven Estimation

Most estimation is story-driven: decompose the work into user stories, estimate each story, and sum the estimates. This works when the architecture is well-understood and the stories are independent. It fails when the architecture is novel, the integration complexity is high, or the stories have hidden dependencies. Architecture-driven estimation starts with the system design and derives effort from the architectural components, integration surfaces, and technology selections — not from the feature list.

1. Component Effort Estimate each architectural component independently: development effort, testing effort, and deployment effort. The order service is 3 weeks of development, 1 week of testing, 0.5 weeks of deployment configuration. The payment integration is 2 weeks of development, 2 weeks of testing (because payment testing requires sandbox environments and edge case coverage), 0.5 weeks of deployment. Component estimates expose where the effort actually lives.
2. Integration Effort Estimate integration separately from component development. Connecting the order service to the payment gateway is a separate effort from building either one. Integration effort includes contract negotiation, error handling design, testing with realistic data, and production verification. Integration effort is consistently underestimated because it is invisible in the component diagram. The 3-layer rule predicts integration effort: each layer adds roughly 1.5x the effort of a single-layer implementation.
3. Uncertainty Multiplier Apply an uncertainty multiplier based on the novelty of each component. Known technology with experienced team: 1.0x. Known technology with new team: 1.3x. New technology with experienced team: 1.5x. New technology with new team: 2.0x. The multiplier is not padding — it is a calibrated adjustment based on the relationship between familiarity and estimation accuracy.