Sonith ManakkatThis is Part A of a two-part playbook for a solo developer or a team of two to five who use AI to do much of the building and want to deliver in short cycles, from one day up to a week. Part A covers the board and the plan. Part B covers roles, meetings, quality gates and release. It follows on from Agile in the age of AI. If you are new to the idea of describing software and accepting what the AI writes, read Vibe coding explained first.
The whole system in one picture
Scrum before and now
Scrum has not been replaced here. The left side of each row is classic Scrum; the right side is how I adapt it for a solo developer or a small team that uses AI to build. Every row is labelled, so you can see which part is established and which part is my own.
Sprint length
My adaptation (not an industry standard)A fixed length of one month or less, decided by the team
One to three days, up to one week, for small AI-assisted teams
Building got faster, so the plan can be re-checked more often.
Planning
My adaptation (not an industry standard)Developers select and size the work they can do in the sprint
Size by how hard it is to verify and how risky it is
The slow part is no longer typing, it is checking.
Backlog items
My adaptation (not an industry standard)Product Backlog items, often written as user stories
Briefs with an outcome and acceptance checks
The AI needs clear checks to build against.
Roles
My adaptation (not an industry standard)Product Owner, Scrum Master, Developers
Who briefs, who reviews, who owns verification; solo means wearing each hat in turn
Same jobs, but small teams share them.
Board
My adaptation (not an industry standard)Not defined by the Guide; To do, Doing, Done is common practice
Ready, AI building, Verify, Ship, Learn
The new columns show where work waits.
Daily check
Proven foundation (still true)Daily Scrum: 15 minutes for the Developers to inspect progress towards the Sprint Goal
Same event, kept short, led by what is waiting in Verify
Still the quickest way to spot a stuck cycle.
Review or demo
Proven foundation (still true)Sprint Review: inspect the outcome with stakeholders
Same idea: show what really works to the person it is for
Real use beats status reports.
Retrospective
My adaptation (not an industry standard)Sprint Retrospective: plan ways to improve quality and effectiveness
Also ends by writing one line into the instruction file
The lesson then reaches the AI too.
Definition of Done
Proven foundation (still true)A formal description of the Increment meeting the quality measures
Same idea, with human review, tests and a safety check added
The shared checklist is classic; its contents are yours.
Velocity and metrics
My adaptation (not an industry standard)Velocity is a common practice, not in the Guide
Watch waiting reviews, rework and how often releases go wrong
Count what shows the loop is healthy.
Release
My adaptation (not an industry standard)An Increment may be delivered during the sprint; the Review is not a gate
Small releases to a few people first, with a way back
Small steps are safer to undo.
Documentation
My adaptation (not an industry standard)Not defined by the Guide; separate documents are common
Instruction files and skills as living, shared process
Notes the AI reads each session stay current.
Where the bottleneck sits
My adaptation (not an industry standard)Not defined by the Guide; commonly building the work
Often reviewing and deciding
Plan around your attention.
- Scrum values
- A goal for each cycle
- Inspect and adapt
- Transparent work
- Empirical process
Many teams still run classic Scrum well. The adaptation is optional; try one row at a time.
| Topic | Classic Scrum (Scrum Guide) | Now (my adaptation) | Label |
|---|---|---|---|
| Sprint length | One month or less | One to three days, up to a week | My adaptation |
| Planning | Developers select and size the work | Size by verification effort and risk | My adaptation |
| Backlog items | Product Backlog items, often user stories | Briefs with acceptance checks | My adaptation |
| Roles | Product Owner, Scrum Master, Developers | Briefer, reviewer, verifier; solo wears each hat | My adaptation |
| Board | Not defined; To do, Doing, Done is common | Ready, AI building, Verify, Ship, Learn | My adaptation |
| Daily check | Daily Scrum, 15 minutes | Same, led by what waits in Verify | Proven foundation |
| Review or demo | Sprint Review with stakeholders | Same, shown to real users | Proven foundation |
| Retrospective | Sprint Retrospective | Adds a line to the instruction file | My adaptation |
| Definition of Done | Quality measures for the Increment | Adds review, tests and a safety check | Proven foundation |
| Velocity and metrics | Common practice, not in the Guide | Waiting reviews, rework, release problems | My adaptation |
| Release | Can happen during the sprint | Small, staged, reversible | My adaptation |
| Documentation | Not defined | Instruction files and skills | My adaptation |
| Bottleneck | Not defined; commonly building | Often reviewing and deciding | My adaptation |
The board for short cycles
Ideas
Briefed (ready)limit 3
AI buildinglimit 1
Verifylimit 2
Ship to testers
Learn
- Idea to Briefed The card gets an outcome, acceptance checks, a risk level and a verify plan.
- Briefed to AI building The AI starts only when the AI building limit has room.
- AI building to Verify A person starts reading the diff and trying it.
- Verify to Rework A check fails, so the card does not move forward.
- Rework to AI building The AI fixes it with the failure noted on the card, and it is verified again.
- Verify to Ship to testers Tests pass, a person read the diff, it ran on a real device, notes are updated.
- Ship to testers to Learn After the test group has used it, the lesson is written down.
Takeaway. A card moves forward only by passing a check, and a failed check sends it back.
- Cycle goal bannerOne sentence about what a user can do afterwards
- Limits on the busy columnsFew things in flight, so work finishes
- Card with brief attachedOutcome, checks, risk level and expected review size
- Blocked on a human decisionQuestions only a person can answer, kept visible
- Verification debt counterChanges built but not yet reviewed; keep it near zero
- Learn columnWhat this change taught us, feeding the instruction file
Expert viewWhy these columns and these limits
The columns follow the path of one change: an idea becomes a brief, the AI builds from the brief, a person verifies, a small test group sees it, and what was learned is recorded. A limit on "AI building" of one item keeps the AI from producing a pile of changes you cannot review; a limit on "Verify" of two forces you to review before asking for more. A paper board works: use sticky notes and write the limit on the column header. The verification debt counter is simply a count of cards in Verify plus any built but unreviewed; when it reaches the limit, you stop starting new work and review. That rule, finish before starting, is the heart of limiting work in progress.
The planning ritual: 30 to 45 minutes
- Pick the outcomeOne thing a user can do afterwards
- SliceInto pieces you can verify separately
- Write the briefOutcome, checks, out of scope, limits
- Split the rolesWhat the AI does, what a human decides
- Verify planHow each slice will be checked
- Ship targetWho sees it and when
- Reserve review timePut it in the calendar first
- Stop conditionWhen to stop, and how to roll back
Expert viewRunning the ritual quickly
Start from the outcome, not the list of tasks. Slice vertically (a thin piece through every layer that a user can notice), then ask of each slice: how will I know it works, how big a diff will it produce, and what is the worst that could go wrong. Write the brief (see Part B for a template), decide the ship target (a small test group, not everyone), and block calendar time for review before any building starts. Stop when the plan is credible; leave the detailed task list for the first slice only, because the plan changes as you learn.
Sizing work for AI: by verification, not typing
- 1Is it unclear how you will verify it?Yes Not ready. Write the acceptance checks first.No keep going
- 2Would reviewing it take more than about ten minutes?Yes Too big. Split it into slices you can verify separately.No keep going
- 3Does it touch money, dates, deletion or privacy?Yes High risk. Size it up and add a check on a real device.No keep going
- 4OtherwiseSmall and low risk. It can enter Briefed.
Takeaway. Size by how hard it is to verify and how bad a mistake would be, not by typing time.
- How big is the review?Small, medium or large diff; large means split it
- How risky is it?Low: a label change. Higher: money, dates, deletion, privacy
- How will I verify it?If you cannot say, the slice is not ready
If you cannot say how you will verify it, it is not ready.
Capacity: your attention is the limit
| Person | Focused hours per day (illustrative) | Share for review and checking | Hours for briefs and decisions |
|---|---|---|---|
| Solo developer | about 4 | about 40% | about 1 |
| Two-person team, each | about 4 | about 40% | about 1 |
| Part-time helper | about 2 | about 40% | about 0.5 |
Capacity here is the number of hours of real attention, not lines of code. A solo developer with four focused hours a day has about twenty hours in a five-day week, of which around eight go on review and verification and around five on briefs and decisions. The numbers are illustrative; yours will differ, so measure for a couple of weeks and adjust.
- Briefs and decisions About one hour writing briefs and answering questions only a person can answer.
- Review and checking About 40 percent, protected first, because verification is the slow part.
- Everything else Supervising the AI, fixes and the daily check.
Takeaway. Book review time first, and plan the rest around it.
Expert viewWhy fewer things in flight finishes things sooner
A simple relationship from queueing theory, known as Little's Law, says that for a stable process the average time an item spends in the system equals the average number of items in progress divided by the average rate at which items finish. In plain words: if you finish about two changes a day and have ten in progress, each takes about five days; with four in progress, about two days. That is why limiting work in progress shortens cycle time without anyone working faster. It is a general result, not a prediction for your project, and it assumes steady flow.
A worked week: a solo developer, one small feature
| Cycle | Plan | What happened |
|---|---|---|
| 1 (Mon to Tue) | Slice: mark a bill as paid, with undo. Brief and verify plan written. Review time booked. | Built in two slices. One review comment fixed. Shipped to a small test group on Tuesday evening. |
| 2 (Wed) | Slice: a paid list screen. | The reminder fired twice after a time-zone change in a smoke test. Not shipped. |
| 3 (Thu to Fri) | Fix cycle 2, then the paid button polish. | Added a test for the time-zone case, fixed it, and added one line to the instruction file. Shipped Friday. |
What went wrong
- A reminder fired twice after a time-zone change
- The smoke test caught it before release
The fix
- A new test for the time-zone case
- A line in the instruction file: always test time-zone changes
What usually goes wrong, and the fix
- A brief that is too bigSplit it until you can review it in ten minutes
- Unreviewed changes piling upRespect the verification debt limit: review before building more
- Scope creep inside a cycleWrite what is out of scope, and put new ideas on the Ideas column
- Skipping the learn stepHold the 15-minute retro and write one line down
- A vague cardAdd acceptance checks and a risk level before it enters Briefed
- Plans that ignore review timeBook review time first
How this relates to Scrum and Kanban
Proven foundation
- An ordered backlog with one person deciding priorities
- Limits on work in progress
- A goal for each cycle
- A retrospective to improve
My adaptation
- A written brief and verify plan for every slice
- Size by verification effort and risk
- A verification debt counter and a stop condition
- Cycles of one to three days
Copy this: cycle plan and card
CYCLE PLAN (30 to 45 minutes)
Cycle goal: one sentence about what a user can do afterwards
Slices (each verifiable on its own):
1.
2.
Brief attached for each slice: yes / no
AI does: ... A human decides: ...
Verify plan: tests / smoke test / real device / review
Ship target: who sees it, and when
Review time booked: day and hours
Stop or rollback condition: ...CARD
Outcome: one sentence
Acceptance checks: 3 to 5 specific things that must be true
Out of scope: ...
Risk: low / medium / high Review size: small / medium / large
Owner (human): ... Brief: attached
Learned: (filled in at the end)Start this week
- Draw the boardSix columns on paper or in any free board tool
- Set two limitsOne item in AI building, two in Verify
- Write one briefOne outcome, three checks, one thing out of scope
- Book review timePut the review hour in the calendar before building
- Hold a 15-minute retroWrite one line for your instruction file
Frequently asked questions
Is this Scrum?
No. It borrows foundations from Scrum and Kanban and says clearly which parts are classic and which are my adaptation.
Can a solo developer do this?
Yes. You hold all the roles, so book time for the verifying hat explicitly. Part B has a hat checklist.
Do I need special software?
No. Paper and sticky notes work, as do free board tools.
Is there evidence that one-to-three day cycles are better?
Not that I can point to. It is my own practice, and the labels say so. Start with a one-week cycle if shorter feels too fast.