Agile for one: what survives the cut.

The problem

Why team agile breaks down when you're the only one.

Scrum's ceremonies exist to synchronize multiple people, surface dependencies, and report upward. Scrum.org's own community concedes that "Scrum events lose value and meaning with a 1-person Development Team," and Michael Gant's widely-cited essay "Scrum and the Solo Dev" answers its own title with a flat "No. Not at all." The structural reasons compound for anyone building alone: your capacity swings from two hours one week to eighteen the next, so any artifact that assumes a constant burn rate — burndown charts, sprint commitments, velocity — mostly measures life events rather than progress. Full solo ceremonies can eat 18–28 hours a month, with no coordination payoff. What survives from Scrum is small and has nothing to do with its ceremonies: an ordered backlog, a definition of done, tasks rightsized to under a day, and the idea of a periodic review.

What survives

Continuous flow, not sprints.

What replaces Scrum isn't "no process" — it's continuous-flow Kanban with light cadences. Personal Kanban (Jim Benson and Tonianne DeMaria Barry) reduces the framework to two rules: visualize the work and limit work-in-progress. Basecamp's Shape Up puts it plainly for tiny teams: "a tiny team can throw out most of the structure… your bets might be different sizes each time: maybe two weeks here, three weeks there." The pattern holds across successful indie builders. Pieter Levels works in 10–12 day obsessive bursts off a paper to-do list; Tony Dinh runs three profitable products on rules like "break work to under-a-day chunks, move slowly, no public ETAs"; Daniel Vassallo's Small Bets treats each project — not each sprint — as the unit of commitment. None of them run sprints, story points, or standups.

The metric that matters

Work item age beats everything else.

If you track one number, track how long each in-progress task has been sitting there. Daniel Vacanti's Kanban Pocket Guide states it bluntly: "Age is by far the most important of all the flow metrics… the single most important aspect is not letting work items age unnecessarily." The reason it beats cycle time is timing: cycle time is a lagging indicator computed only on finished work, while work item age is a leading indicator of items currently stuck. For a solo builder, lagging data is nearly useless — there's no one else to flag a bottleneck, so the only person who can intervene is the same person creating the stall. Aging also catches the work that's most damaging to a one-person operation: the half-built project that never finishes. The enforcement rule is Vacanti's "stop starting, start finishing" — clear the oldest, stuck item before pulling anything new.

The right scoreboard

Throughput, not velocity. Burnups, not burndowns.

Story points were designed to absorb individual variation through team averaging — and one person provides no averaging, so they collapse into false precision. The pragmatic solo metric is a rolling four-week count of items completed, shown as a calibration tool against your own baseline, never as a goal — the moment a number becomes the target you start gaming it (Goodhart's Law), even with an audience of one. Burndown charts fail solo for the same reason sprints do: they presume a constant capacity, and they hide the dominant personal-project pathology — scope creep — by collapsing scope and progress into one line. A burnup separates them, so growth in scope becomes visible while it's happening. Skip cumulative flow diagrams entirely; at solo scale their signal washes out in noise you can already see by glancing at the board.

The cadence that holds it together

Goals you can see, and a Friday review.

Locke and Latham's goal-setting research — the strongest evidence base in this whole area, and largely run on individuals, not teams — found specific, challenging goals beat "do your best" in about ninety percent of studies. The team apparatus around OKRs is optional; the idea of a small set of explicit quarterly outcomes is not. Keep the cascade to two levels, quarter to week, with at most three goals. Then the highest-leverage practice of all: the weekly review. David Allen calls the GTD weekly review "the master key"; Tiago Forte's version takes about thirty minutes on a Friday. The trick is to make it respond to facts rather than reconstruct memory — surface what you finished, what's aged, and what scope changed, then answer a handful of questions (Anne-Laure Le Cunff's Plus / Minus / Next works well) and name one to three objectives for next week.

The features

What survived the cut — in Zoro.

Zoro ships the survivors and leaves out the ceremony. Every feature below maps to a finding above; the absences are the point as much as the features.

FAQ

Solo agile, answered.

Sources

Where this comes from.

• Daniel Vacanti, Colleen Johnson, Prateek Singh — The Kanban Pocket Guide, and Vacanti, When Will It Be Done? (work item age, throughput, forecasting).
• Jim Benson & Tonianne DeMaria Barry — Personal Kanban (visualize work, limit WIP).
• Basecamp — Shape Up, "Adjust to Your Size" (variable-length bets for tiny teams).
• Scrum.org — community guidance on Scrum at N=1, and "Bye Bye Velocity. Hello Throughput"; Michael Gant, "Scrum and the Solo Dev."
• Edwin Locke & Gary Latham — goal-setting theory (specific, challenging goals; studied on individuals).
• David Allen — Getting Things Done (the weekly review); Tiago Forte (30-minute Friday review); Anne-Laure Le Cunff (Plus / Minus / Next).
• Sophie Leroy — "Why is it so hard to do my work?" attention-residue study (OBHDP, 2009); Cal Newport, Deep Work; Gloria Mark (refocus cost).
• Practitioner patterns: Pieter Levels, Tony Dinh, Daniel Vassallo (Small Bets), John Cutler ("Inputs First").

Related

Keep reading.