Skip to main content
< All Topics
Print

Scope Control

name: scope-control

description: Evaluate scope change requests, manage a parking lot backlog, and enforce sprint boundaries to prevent scope creep in vibe-coded projects. Use when an informal feature request appears mid-build, when reviewing sprint scope, or when a prompt starts with “while you’re at it, also add…”

Scope Control

Instructions

Enforce scope discipline in AI-assisted development to prevent vibe-coding pitfall 9 (scope creep via prompt).

Scope creep detection triggers:

  • Any prompt containing “while you’re at it…”
  • Any prompt containing “also add…” or “can you quickly…”
  • Any request for functionality not traceable to an approved requirement
  • Any mid-session request that changes data models, API contracts, or user-facing behavior

When a scope change is detected, apply this protocol:

1. Classify the request

Classification Criteria Action
Bug fix Existing feature doesn’t work as specified Fix immediately — this is not scope creep
Clarification Requirement is ambiguous; this resolves ambiguity Document the clarification in requirements; proceed
Enhancement Adds capability beyond the current requirement Evaluate via change request (step 2)
New feature Entirely new capability not in requirements Add to parking lot (step 3)

2. Change request evaluation (for Enhancements)

Answer these four questions:

  1. Impact: Does this change the data model, API contract, or architecture? (If yes, architecture review required)
  2. Effort: Can this be completed within the current sprint without displacing planned work? (If no, defer)
  3. Risk: Does this introduce untested surface area without time to write tests? (If yes, defer)
  4. Value: Does the stakeholder confirm this is higher priority than the item it displaces? (If no, defer)

If all four pass: approve the change, update the requirements document, proceed. If any fail: add to parking lot.

3. Parking lot management


## Parking Lot — [Product Name]
**Last Updated**: YYYY-MM-DD

| ID | Request | Source | Date Added | Priority | Status |
|----|---------|--------|------------|----------|--------|
| PL-001 | [Description] | [Session/person] | YYYY-MM-DD | High/Med/Low | Parked / Scheduled / Declined |

Rules:

  • Every parked item gets a priority at the end of the sprint
  • Top 3 items by priority are candidates for the next sprint
  • Items parked for 3+ sprints without scheduling are reviewed for decline

4. Sprint lock protocol

At the start of each sprint/milestone:

  1. Scope is locked — the list of requirements/stories is frozen
  2. Changes require a change request evaluation (step 2)
  3. The scope owner (Product Manager or Peter) has authority to approve or deny

Response to informal scope requests:

“That’s a good idea. I’ve added it to the parking lot as PL-[number]. We’ll prioritize it for the next sprint. For now, let’s stay focused on [current requirement].”

Outputs: Scope change classification, change request evaluation, parking lot entry, sprint scope lock declaration.

Table of Contents