Scrum was designed for a 5–9 person team with a dedicated Scrum Master and Product Owner. Below three people, the ceremony costs more than it delivers. Here is what to do instead.
Scrum is honest about its target. The Scrum Guide specifies a team of professionals delivering a product Increment — typically 5 to 9 developers, plus a Scrum Master and a Product Owner. That is the design. When you read the Guide carefully, almost every ceremony assumes:
A team of three has none of those things. The PO is also coding. The Scrum Master is also coding. Synchronization across three people happens in Slack in two minutes. The Sprint Review audience is the founder, who already knows. The retrospective fits in lunch.
So when small teams "do Scrum," they do cargo-cult Scrum: the ceremonies happen on schedule, but they don't solve real problems. They consume hours, generate guilt, and create the appearance of process where there is none. The team would ship more if the ceremonies didn't exist.
| Ceremony | Why it exists | Replace with |
|---|---|---|
| Daily Standup | Synchronization across a team large enough to drift out of sync | Async daily note in Slack/Discord. Two sentences. No meeting. |
| Sprint Planning | Forecasting capacity over a 1–4 week boundary | Continuous prioritization. Top of backlog is what's next. No batch. |
| Sprint Review / Demo | Stakeholder visibility into what was built | Daily ship + changelog. Stakeholders see it in production, not a demo. |
| Retrospective | Team-level feedback loop on the process itself | Fold into the Nightly Ritual. One question: "What slowed me down today?" |
| Backlog Grooming | Keeping a multi-sprint backlog estimable and ordered | Maintain a 5–10 item "next" list. Anything beyond that is fiction. |
The default for small teams building production product. No sprints. No ceremonies. No dedicated roles. The discipline is a single invariant: the main branch is always deployable, and a ship happens every working day. Feature flags handle release management. CI handles QA. The Nightly Ritual handles team-level feedback. Read the SSD page.
Best when work clusters into discrete features that take weeks, not days. Six-week cycles, two-week cool-down, betting table to decide what to build next. The hill chart replaces standups as the visibility tool. Works for 3–5 person teams that have a real product manager (even if part-time) and a stakeholder who participates in betting.
Best for support, operations, or unpredictable interrupt-driven work. WIP limits + pull-based flow + a board. No iterations, no estimates, no ceremonies. The board is the meeting. Pair it with SSD for the deployment discipline that Kanban itself does not provide.
To be fair: Scrum genuinely helps when a team has 6+ engineers, a real PO, real stakeholders who need cadence, and work that benefits from a sprint boundary. Enterprise software with quarterly stakeholder rhythms is exactly Scrum's home turf. The argument here is not "Scrum is bad" — it is "Scrum is wrong for three people."
SSD is designed for the team you actually have.
Read SSD