# How We Scope Projects (And Why Most Estimates Are Wrong)

- **Category:** Process
- **Date:** 2026-01-10
- **Read time:** 5 min

Bad estimates kill projects. A client expects X, the developer estimated X but actually needed 2X, and everyone ends up frustrated. Here's how we avoid that.

## Why estimates go wrong

The #1 reason: scope is vague. "Build a CRM" means wildly different things to different people. If the scope document has any sentence that could be interpreted two ways, it will be - in the most expensive direction.

## Our scoping process

### 1. Problem definition (not solution definition)

We start with what's broken, not what to build. "Our team spends 10 hours a week on manual data entry" is a better starting point than "we need an integration."

### 2. User story mapping

Every feature is written as a user story with acceptance criteria.

### 3. Explicit exclusions

What we're NOT building is as important as what we are. We list exclusions in every scope document.

### 4. Buffer for the unknown

Every project has unknowns. We build in a 15-20% buffer and tell the client about it upfront. If we don't use it, the project comes in under budget.

## The deliverable

Our scope documents include: user stories with acceptance criteria, technical architecture overview, explicit exclusions, timeline with milestones, and fixed pricing tied to the defined scope.

If scope changes - and it sometimes does - we document the change, adjust the estimate, and get approval before proceeding. No surprise invoices.