Most "agile" implementations at small startups are sprint theater. Two-week sprints, planning meeting, daily standup, demo, retro — 4-6 hours per person per week of process overhead. At 3-engineer teams, that is 15-20% of capacity spent on process that produces almost no benefit.
The right answer for most small teams is Kanban with light structure. The right answer for larger teams or stakeholder-heavy environments is sprints. This post draws the line concretely and walks through the metrics that matter regardless of which you pick.
Scrum Overhead at Small Team Sizes
The math at 3 engineers
- Sprint planning: 2 hours every 2 weeks = 1 hour/week
- Daily standup: 15 min × 5 days = 1.25 hour/week
- Sprint review/demo: 1 hour every 2 weeks = 0.5 hour/week
- Sprint retro: 1 hour every 2 weeks = 0.5 hour/week
- Backlog grooming: 1 hour every 2 weeks = 0.5 hour/week
Total: 3.75 hours/week per engineer × 3 engineers = 11.25 hours/week. At 40-hour weeks, that is 9.4% of total capacity. Plus the context-switching cost, plus the management time. The real number is 15-20%.
The math at 8 engineers
Same per-engineer overhead, but the coordination value scales. 8 engineers without sprints means 8 people stepping on each other's work, unclear priorities, parallel duplicated work. The 15-20% process tax buys coordination that pays back 30-40% in reduced rework.
WIP Limits in Kanban
The single most important Kanban concept: work-in-progress limits. Each column on your board has a maximum number of cards allowed. When the limit is hit, no new work can enter — focus on finishing what is started.
Typical WIP limits
- To Do: unlimited (it is the backlog).
- In Progress: 1-2 per developer. So 3 developers = 3-6 total.
- In Review: 2-3 total (forces fast review turnaround).
- Ready to Deploy: 1-2 (forces fast deploys).
What WIP limits actually do
Force the team to finish work before starting new work. The temptation when stuck on a task is to start a new one. With WIP limits, you must instead unblock the stuck task — pair, escalate, simplify. This reduces context switching and shortens cycle time.
The hardest WIP limit to enforce: "In Review." Engineers do not like to interrupt their flow to review someone else's PR. WIP limit on review forces the team to treat reviewing as first-class work, not an afterthought.
Cycle Time vs Velocity
Scrum measures velocity (story points completed per sprint). Kanban measures cycle time (time from work started to work shipped). Cycle time is the better metric.
Why cycle time wins
- Objective: measured in hours/days, not subjective points.
- Cannot be gamed: you cannot fake faster work without actually shipping faster.
- Customer-facing: shorter cycle time = faster response to customer needs.
- Improvable: you can identify and remove bottlenecks. Story points cannot improve as a metric.
Healthy cycle time targets
- Trivial task: under 1 day (typo fix, copy change).
- Small feature: 1-3 days.
- Medium feature: 1-2 weeks.
- Large feature: if over 2 weeks, break it down. Cycle time over 2 weeks indicates poor decomposition.
The metric to watch: median cycle time per task. Trending down month-over-month = healthy process. Trending up = something is wrong (more tech debt, more context switching, or growing scope per task).
When Sprints Actually Add Value
External stakeholder commitments
Sales is pitching a customer and needs to commit to "this feature will be live by end of month." Marketing is planning a launch around a specific feature. Customer Success has promised an enterprise customer a fix by their renewal date.
Sprints create predictable batched delivery that maps to these commitments. Kanban's "we will ship when it is ready" does not work when external parties have committed to "by date X."
Coordination at scale
5+ engineers working on the same product need a coordination ritual. Sprint planning is that ritual. It forces alignment on priorities, surfaces conflicts, and produces a shared two-week commitment.
Below 5 engineers, the coordination can happen informally. Above 5, it cannot.
Natural batching
Mobile apps with App Store review cycles benefit from sprints — you batch features for the next release. Same for products with monthly billing cycles (new features tied to billing period). Same for B2B enterprise products where customers expect quarterly releases.
When Kanban Wins
Small teams (under 5)
Process overhead is high % of capacity. Coordination cost is low. Kanban wins.
Support-heavy environments
If 30%+ of work is reactive (bug fixes, customer support issues, incident response), sprints constantly get disrupted. Kanban absorbs interrupt work naturally.
Continuous deployment products
Web apps that deploy multiple times per day. Features go live as they are ready, not batched. Sprints add friction without benefit.
Pure internal product work
No external commitments. Team can ship when ready. Cycle time matters more than predictable batch delivery.
Agile vs Kanban Compared
| Dimension | Scrum / Sprints | Kanban |
|---|---|---|
| Team size sweet spot | 5-9 | 2-15 |
| Process overhead | 10-20% of capacity | 3-7% of capacity |
| Coordination value | High | Medium |
| Predictability | High (sprint commitments) | Lower (cycle time distribution) |
| Handles interrupts | Poorly (disrupts sprint) | Naturally (no batch boundary) |
| Key metric | Velocity | Cycle time |
| Decision-making | Batched at sprint boundary | Continuous |
The Hybrid Approach
Most successful 5-10 engineer teams I have seen run a hybrid:
- Kanban-style flow: WIP limits, continuous deployment, no sprint commitments.
- Weekly check-in: 30-minute meeting Monday morning to align on priorities for the week. Not planning, just alignment.
- Monthly demo: show progress to the broader team / stakeholders. Replaces sprint demo.
- Monthly retro: 1-hour process retrospective. Adjust the process based on what is working.
Total overhead: 2-3 hours/week per engineer. Same coordination value as sprints with 1/3 the process tax.
What Not to Do
- Do not run sprints at 3 engineers. The math does not work.
- Do not measure velocity as a performance metric. Engineers learn to estimate larger for the same work.
- Do not skip WIP limits in Kanban. Without them, Kanban is just a To-Do list and produces no benefit.
- Do not have a 1-hour daily standup. 15 minutes max. If it takes longer, the team is too big or the format is wrong.
- Do not have a Scrum Master role at small teams. Process facilitation is part of the team lead's job.
- Do not commit to sprint scope before the sprint starts. Plan, then adjust as reality unfolds.
The Process Smell Test
If the engineering team consistently complains about process meetings, the process is wrong. The complaint is the signal — investigate, do not dismiss.
If sprints feel like ceremonies that produce no decisions, the team should be on Kanban. If Kanban feels chaotic and priorities shift constantly, the team needs sprint structure. The signal is the team's experience, not the framework's name.
Process Evolution Over Time
- 1-3 engineers: Kanban with weekly priorities meeting. No formal process.
- 4-7 engineers: Kanban with WIP limits + monthly demo + monthly retro.
- 8-12 engineers: Sprints OR Kanban with stronger coordination. Either works.
- 12+ engineers: Sprints with sub-teams owning specific areas. Pure Kanban breaks down.
Re-evaluate process every 6-12 months. The team size at which process changes is gradual — usually you notice the old process is hurting before you change it.
Engineering process review
If your team is complaining about process or you are not sure which framework fits your stage, I do 60-minute process reviews. You leave with a specific recommendation and a 30-day transition plan.
Book a discovery call