Why Scope Creep Happens
Scope creep doesn't usually happen because founders are dishonest or developers are lazy. It happens because scope was never clearly defined in the first place. When the brief is ambiguous, every reasonable interpretation generates a new conversation. Every new conversation can become a new feature. Every new feature adds time and cost.
The solution is not better developers or more experienced PMs. It's a cleaner scoping process at the beginning.
The Scope Lock Protocol
Step 1: Write the MRD (3 sentences)
The Minimum Requirements Document is not a 20-page spec. It is three sentences:
- What are we building?
- Who is it for?
- What does success look like?
These three sentences must be agreed and signed before any other work begins.
Step 2: Feature taxonomy
List every feature you want. Then classify each one:
P0: Must have for launch. The product does not work without this. P1: Should have for launch. Launch is weaker without it but possible. P2: Nice to have. Goes into sprint 2. P3: Good idea, not now. Goes into the product backlog.
The default bias should always be toward deferring. Features have a way of expanding once you start building them. Features on paper are always smaller than features in production.
Step 3: Story mapping the P0s
For each P0 feature, write one user story: "As a [user], I can [action], so that [outcome]." This forces specificity. "Users can manage their account" is not a story. "Users can update their email address and receive a confirmation email" is.
Story mapping reveals hidden sub-features. "Checkout" contains: item summary, discount code validation, payment processing, confirmation email, and error states. Each sub-feature adds time. Listing them explicitly before the sprint starts prevents surprises.
Step 4: Explicit out-of-scope list
The out-of-scope list is as important as the in-scope list. Write it. Common out-of-scope items for first sprints:
- Analytics dashboard (use third-party tools: PostHog, Amplitude)
- Admin panel (build it in sprint 2)
- Multi-language / i18n support
- Custom email templates (use a default template)
- Mobile app (ship web first)
Step 5: Definition of Done
Agree on what "done" means before work starts. Done usually means:
- All P0 features are live in production
- Core user flow passes QA
- No P0 bugs open
- Basic accessibility check passed
"Done" does not mean: every edge case is handled, every potential feature is built, the stakeholder hasn't thought of any more ideas.
The Change Request Process
Once scope is locked, any addition must go through a change request:
- Describe the new requirement in writing
- Estimate impact on timeline and cost
- Get explicit approval before adding it to the sprint
This is not bureaucracy. This is protecting the founder's budget and the team's timeline. Teams that skip this step see scope expand by 30–50% on average.
FAQ
Q: What if I discover a required feature mid-sprint?
Process it as a change request. If it's truly a P0 discovery, it gets added and either the timeline extends or something else gets cut. This trade-off should be explicit.
Q: How specific does the brief need to be?
Specific enough that two different engineers would produce the same feature if given only the brief. If there are multiple reasonable interpretations, the brief needs more detail.
Q: What's a reasonable sprint velocity for a small team?
1 experienced engineer can build 1–2 well-defined features per week. Planning more than this consistently leads to crunch, compromised quality, or both.
Q: Should I involve the development team in scoping?
Yes. Engineers who scope their own work produce more accurate estimates and more realistic timelines. Scope decided without engineering input is a guess. Scope decided with engineering input is a plan.