Let me say upfront: Scrum works. For 50-person engineering teams at enterprise companies coordinating across multiple squads, Scrum provides structure that prevents chaos. That's what it was designed for.
We're a 4-person development team building MVPs for regulated industries. We ship complete products in 8-12 weeks. Scrum's overhead — sprint planning, daily standups, sprint reviews, retrospectives, backlog grooming — was consuming 15-20% of our development capacity without providing proportional value.
So we built our own process, inspired by Basecamp's Shape Up, tuned for small teams building MVPs with compliance requirements.
The Problem with Scrum at Our Scale
1. Story Points Are Theater
We used to estimate in story points. A "3-point" story for one developer was an "8-point" story for another, depending on familiarity with the codebase area. So we'd discuss and converge on a number that made everyone comfortable — which was neither accurate nor useful.
Story points give the illusion of precision. "We have 40 story points of velocity" sounds data-driven. But when a 5-point story takes 3 days one sprint and 1 day the next, the metric is measuring team mood, not complexity.
2. Two-Week Sprints Create Artificial Boundaries
Building HIPAA-compliant platforms or FDA-regulated software involves features that don't fit neatly into 2-week boxes. An audit logging system takes 5 days. A role-based access control layer takes 8 days. Neither fits cleanly in a sprint, so you either split them artificially (breaking the developer's flow) or carry them across sprints (defeating the purpose of sprint boundaries).
3. Ceremony Overhead at 4 People Is Absurd
Let's count the hours:
| Ceremony | Time/Sprint | People | Person-Hours |
|---|---|---|---|
| Sprint Planning | 2 hours | 4 | 8 hrs |
| Daily Standup | 15 min × 10 days | 4 | 10 hrs |
| Sprint Review | 1 hour | 4 | 4 hrs |
| Retrospective | 1 hour | 4 | 4 hrs |
| Backlog Grooming | 1 hour | 4 | 4 hrs |
| Total per sprint | 30 person-hours |
30 person-hours per 2-week sprint. A 4-person team has 320 available person-hours per sprint (4 × 8 × 10). That's 9.4% just on Scrum ceremonies — before you add context switching, meeting prep, and the post-meeting unfocusing time. Realistically, 15-20% of capacity.
For a team of 50, this overhead is amortized across enough people that it's worth it. For a team of 4, it's a tax on shipping speed.
What We Do Instead: Shaped Cycles
Our process borrows heavily from Basecamp's Shape Up, adapted for agency work building MVPs for external clients.
Shaping (Before Development)
Before a single line of code, we "shape" the work. Shaping means defining the problem and solution at the right level of abstraction:
- Problem definition — What user problem are we solving? (Not "build feature X" but "users can't find documents faster than 15 minutes")
- Appetite — How much time is this worth? (2 days? 1 week? 3 weeks?)
- Solution sketch — Enough detail that developers know the approach, abstract enough that they make implementation decisions
- Rabbit holes — Known risks and complexity traps, called out explicitly so developers can avoid them
- No-gos — What we're explicitly NOT building (prevents scope creep)
Appetite, not estimates
Instead of asking "how long will this take?" we ask "how much time is this worth?" If we decide a feature is worth 1 week, we shape it to fit 1 week. If it can't fit, we cut scope or split it. This flips the dynamic: timeline drives scope, not scope drives timeline. The result: we deliver what matters within the time budget, rather than blowing past estimates.
Fixed-Time Cycles (During Development)
Instead of 2-week sprints, we use flexible cycles based on the project's natural rhythm. For a typical 10-week MVP:
- Week 1-2: Foundation cycle — Database schema, authentication, infrastructure, core API skeleton
- Week 3-6: Feature cycles — 1-2 week cycles per major feature area, shaped independently
- Week 7-8: Integration cycle — Connect features, end-to-end testing, compliance verification
- Week 9-10: Hardening cycle — Performance, security, deployment, documentation
Each cycle has a fixed time budget and shaped scope. If something takes longer than the budget, we cut scope — we don't extend the cycle. This creates natural pressure to build the simplest thing that works.
Async Communication (Instead of Meetings)
We replaced Scrum's meeting-heavy communication with async-first patterns:
- No daily standups. Instead: daily async check-in via Slack. "Shipped: [thing]. Building: [thing]. Blocked: [nothing/thing]." Takes 2 minutes to write, 1 minute to read.
- No sprint planning meetings. Instead: shaped work is documented in a brief (1-2 pages). Developers read it, ask questions async, and start building.
- No retrospectives. Instead: a "lessons learned" section in every project's wrap-up document. We review these before starting similar projects.
- Weekly client demo. This is our only recurring meeting. 30 minutes, once a week. We show working software, get feedback, adjust priorities for next week.
Total meeting overhead: 30 minutes per week (client demo) + ad-hoc pairing sessions when someone needs help. Compare to Scrum's 15+ hours of ceremonies per sprint.
How This Works for Regulated Industries
You might think: "Compliance requires rigid processes. How does this work for HIPAA or FDA-regulated software?"
Actually, shaped cycles work better for compliance than sprints. Here's why:
Compliance is shaped upfront, not discovered mid-sprint. When we shape the "Authentication" cycle for a healthcare platform, the shape explicitly includes: "RBAC with 3 role levels, MFA for PHI access, 15-minute session timeout, audit logging on every auth event." These aren't user stories that surface during backlog grooming. They're constraints built into the shaped scope from day one.
Fixed-time budgets force compliance prioritization. In Scrum, compliance features compete with business features for sprint capacity, and compliance often loses ("we'll add audit logging next sprint"). In our shaped cycles, compliance is baked into the time budget. The authentication cycle IS the compliance cycle.
For GuardianRx (DEA compliance platform), we shaped the compliance requirements as explicit cycles: "Week 3-4: Audit trail + RBAC" and "Week 5-6: WebRTC witnessing + biometric auth." Each cycle had compliance acceptance criteria defined in the shape. No ambiguity, no "we'll get to it later."
The Results: What Changed When We Dropped Scrum
| Metric | With Scrum | Shaped Cycles |
|---|---|---|
| Meetings per week | 5-7 | 1 (client demo) |
| Ceremony overhead | 15-20% | 3-5% |
| Avg MVP delivery | 12-16 weeks | 8-12 weeks |
| Scope creep incidents | 2-3 per project | Rare (appetite-based scoping) |
| Developer satisfaction | Mixed (meeting fatigue) | High (long focus blocks) |
The biggest win isn't the meetings saved — it's the focus time recovered. A developer who has 4-hour uninterrupted blocks builds better software than one who's interrupted every 90 minutes by a ceremony.
When Scrum IS the Right Call
We're not anti-Scrum. We're anti-wrong-tool-for-the-job. Scrum works well when:
- Large teams (10+ developers) — Coordination overhead justifies ceremony overhead
- Unclear requirements — When the product vision is fuzzy and you need iterative discovery with stakeholders every 2 weeks
- Multiple product owners — Sprint reviews with competing stakeholders create alignment that async can't
- Junior-heavy teams — The structure helps less experienced developers plan and commit
If any of those describe your situation, Scrum is probably fine. If you're a small, senior team building defined products, consider whether the ceremony is serving you or you're serving the ceremony.
Frequently Asked Questions
What's wrong with Scrum for small teams?
Ceremony overhead (sprint planning, standups, reviews, retros, grooming) consumes 15-20% of a 4-person team's capacity. Story points create false precision. Two-week sprints force artificial scope boundaries for features that don't fit neatly into 2 weeks.
What is Shape Up?
Basecamp's development methodology. Instead of sprints with story points, it uses fixed-time cycles with shaped work. Shaping means defining the problem and approach at the right abstraction level. Work has a time budget (appetite), not an estimate. Either it ships in the cycle or scope gets cut.
How do you estimate without story points?
Appetite-based scoping. Instead of "how long will this take?" we ask "how much time is this worth?" If a feature is worth 1 week, we shape it to fit. If it can't fit, we cut scope. Timeline drives scope, not the reverse. After 50+ MVPs, our 8-12 week delivery window is based on shaped scope.
Does this work for regulated industries?
Yes. Compliance requirements become constraints in the shaping phase, not surprises during development. We shape compliance features (audit logging, encryption, access controls) as explicit work items with fixed time budgets. This works better than discovering compliance scope mid-sprint.
Do you do daily standups?
No. We do async Slack check-ins: what shipped, what's building, what's blocked. 2 minutes instead of 15. Blockers get posted immediately to a Slack channel, not held until tomorrow's standup.
Next Steps
- Book a 30-minute call — we'll explain how our process works for your specific project type
- $35k MVP vs $200k MVP — how our process translates to pricing and scope
- Why We Don't Do Discovery Phases — another contrarian process opinion
- SaaS MVP Development — our process, pricing, and what you get