Feature scoping

Feature Scoping

Part of the discovery-phase skill pack · scoping group · reads discovery-context.md (run profile-builder first if missing).

The boundary-drawing skill. Output is a scope doc precise enough that engineering can estimate it and the client can sign off on it. Built to be paste-able into a proposal or SoW (commercial documents) with minimal rework.

Step 1 — Read context

Read discovery-context.md (sections 3. Engagement, 5. Expected deliverable, 6. Constraints), opportunity-tree.md (solution direction), and risk-assumption-map.md (top assumptions to retire).

If discovery-context.md is missing, ask the BA inline: "(a) timeline + budget shape (days / weeks / month / quarter); (b) any hard constraints (NDA / regulatory / tech-stack lock-in)?" — tag the output [ASSUMED ENGAGEMENT]. If opportunity-tree.md is missing, ask for solution direction in one line, or proceed tagged [NO-SOLUTION-DIRECTION]. If risk-assumption-map.md is missing, ask for 1–3 top assumptions to retire, or proceed tagged [NO-RISK-FRAME]. Never block; recommend profile-builder / opportunity-mapping / risk-assumption-mapping for high-stakes work.

Step 2 — State the MVP job

One sentence. "The scope lets <user> do <task> in <context>, such that <top assumption from risk-map> is retired."

This anchors scope to assumption-retirement, not feature completeness.

Step 3 — Draw the scope line — 11 areas

Every row must have BOTH in and out. Ambiguity is where mid-build scope creep lives. If a row is genuinely "TBD", say so explicitly with a deadline for resolution, but don't leave blanks.

Area	In	Out
Users / segments	Which segment / seats	Which segments excluded
Core flow	The one happy path	Alternative flows
Auth	Existing SSO / new login	Role-based permissions
Data	Read / write, persistence	Migrations, historical data
Integrations	The 1 must-have	All others
UI polish	Rough / polished / designer-built
Error handling	Which errors shown, which swallowed
Observability	What we'll log to learn	Full prod telemetry
Platforms	Web / mobile / CLI
Accessibility	A11y floor (e.g., keyboard-only ok, screen reader later)
i18n	English-only or specific languages

Step 4 — Define success metrics

Two pre-committed numbers:

• Leading metric — engagement signal during the build window (e.g., 40% of invited users complete core flow within 7 days)
• Lagging metric — the problem-canvas success signal at scope + 4 weeks

State pivot/kill thresholds (consumed by go-nogo-memo later).

Step 5 — Rollout boundary

Pick one based on engagement mode (per discovery-context.md section 3):

• Pre-sale demo: agency-hosted, no real users
• Discovery-sprint output: client internal dogfood
• Delivery-phase MVP: 5-10 friendlies, % feature flag on real users, or separate URL/product
• Staff aug: mirror client's existing rollout pattern

Include a rollback criterion ("if metric X drops below Y in 48h, disable flag").

Step 6 — Engineering size estimate

T-shirt: S (<1 wk), M (1-3 wk), L (>1 mo). If L, loop back to Step 3 and cut. Discovery-sprint scopes should be S or M.

The actual hour-level estimate is estimation skill's job. This skill produces the t-shirt for early reality-check.

Step 7 — Explicitly deferred list

5-15 bullet items titled "Explicitly deferred". This list gets referenced at every standup during build to prevent re-litigation. In a proposal/SoW context, this becomes the "Out of Scope" section.

Step 8 — Outsourcing-specific extras

Add at bottom:

• Assumptions of the client (from risk-assumption-map.md rows tagged [client] or [shared]) — what the client must do/provide for this scope to be valid
• Agency dependencies — what the agency needs from third parties or other team members

These flow directly into the proposal "what we need from you" / "our dependencies" sections.

Output

./discovery/scope-doc.md per ./template.md. Designed to be reused — proposal and sow-draft skills will pull sections from here verbatim.

Append to _log.md: [feature-scoping | YYYY-MM-DD] mvp_job: <one-line>; tshirt: <S/M/L>; deferred: <count>; client_assumptions: <count>.

Anti-patterns

• Scope by feature list. Features without a user job create orphan UI. Lead with the job.
• Open-ended MVP. No date or success metric → not an MVP, just a build.
• Hidden auth/data/integration changes. "Just a small change to auth" is how 3-week projects become 3-month projects. Put it explicitly in in or out.
• Scope identical to opportunity-tree. OST names solutions; scope picks one slice of one solution. Same size = scope is too big.
• Skipping assumptions/dependencies for outsourcing. These exist in any internal scope too, but in outsourcing they become legally/commercially load-bearing. Be explicit.