One-Feature Scope: ship real value faster by cutting everything else

TL;DR: Write a one-sentence spec — “This sprint improves X for Y by Z.” Everything else goes to a Later list. Then build, ship, learn.

Constraining scope reduces WIP, cuts switching costs, and accelerates feedback.

What is One-Feature Scope?

One-Feature Scope is a constraint that forces clarity: pick one outcome for one audience with one mechanism, and ship just that. It’s the antidote to feature bloat, wandering sprints, and “almost done” work.

Spec template:

This sprint improves X (outcome) for Y (who) by Z (approach).
Non-goals: A, B, C.
Done when: measurable acceptance criterias 1–3.

Why it works

The science in plain English

• Less WIP → faster flow. Limiting work-in-progress lowers lead time (Little’s Law). Fewer items in the pipe means faster completion.

• Fewer context switches. Multitasking taxes working memory and increases time/effort; single-feature focus avoids the switching cost.

• Stronger follow-through. Turning intent into a concrete plan (“At 10:00 we ship Z for Y”) boosts execution (implementation intentions).

• Motivation snowball. A visible finish line triggers the goal-gradient effect — effort rises as completion nears.

• Better learning loops. Lean cycles (build-measure-learn) depend on small, testable slices; one feature = cleaner signal.

Step-by-step: Run a One-Feature Sprint

1. Write the spec (3 min). Use the template above. Add 2–3 acceptance criteria and explicit non-goals.

2. Kill WIP (2 min). Park everything else on a Later list. No parallel tickets.

3. Plan the slice (5 min). Smallest viable path to satisfy the acceptance criteria.

4. Timebox (e.g., 1–2 × 30/5 blocks). Build the slice; no new scope mid-block.

5. Ship a concrete artifact. PR, prototype link, live toggle, doc, or case study.

6. Measure + note. Capture one metric tied to the outcome and one learning for the next iteration.

Recipes by role (use as-is)

• Developers: “Improve signup completion for new users by adding email-only flow.”

  • Done when: conversion ↑ ≥ 10% on A/B, no error spikes, <100ms latency hit.

• Designers: “Improve scanning for pricing page by restructuring tiers.”

  • Done when: first-click success ≥ 80% in 5-user test; bounce ↓ on /pricing.

• Writers/Marketing: “Increase CTR for hero by testing 3 headline variants.”

  • Done when: variant beats control by ≥ 8% over 7 days.

• Students: “Raise practice accuracy on integrals by 15%.”

  • Done when: 10 problems in a row ≥ 90% with timed conditions.

Team play (30 minutes)

• 10: Align on Y (who) and X (outcome).

• 10: Draft the spec + acceptance + non-goals.

• 10: Identify the smallest viable slice; assign one owner; schedule two 30/5 blocks.

Common pitfalls (and quick fixes)

• Vague outcomes. Add a verb + metric (“increase, reduce, shorten by N%”).

• Hidden dependencies. Stub or fake it for now; capture real integration for v2.

• Scope creep mid-sprint. Move new ideas to Later; revisit after you ship.

• Shipping polish, not value. Ask: “Would a user notice?” If not, cut it.

Make it a habit (metrics to watch)

• Lead time (ticket start → ship)

• Throughput (# one-feature ships/week)

• WIP (keep at 1 per person)

• Outcome metric tied to the spec (conversion, time-to-first-value, etc.)

Right now, write your one-sentence spec (“This sprint improves X for Y by Z.”). Block 2×30/5 on your calendar today, build the smallest slice, and ship one artifact before you sleep. Tomorrow morning, log one metric that moved.