You’ve been doing Scrum for years.
Two-week sprints. Daily standups. Story points. Sprint planning. Retrospectives.
And it’s exhausting.
The sprints feel arbitrary. The planning meetings drag on. The backlog is a graveyard of ideas no one will ever build.
You’re shipping, but it feels like running on a treadmill.
What if there’s a better way?
In 2019, Basecamp published “Shape Up”—their alternative to Scrum.
The core idea:
- Work in 6-week cycles (not 2-week sprints)
- Fixed time, variable scope (not fixed scope, variable time)
- No backlog (ideas don’t pile up forever)
- Betting, not planning (leadership commits to ideas worth doing)
- Shaping, not speccing (rough outlines, not detailed specs)
It’s radically different from Scrum.
And for many teams, it’s radically better.
The Problem with Scrum
Scrum has good ideas. But for many teams, it doesn’t work well.
Problem 1: Two Weeks Is Too Short
Two-week sprints mean:
- Constant context switching
- Perpetual planning meetings
- No time for deep work
- Everything feels urgent
You spend more time planning than building.
Problem 2: The Backlog Is a Lie
In theory: The backlog is a prioritized list of work.
In reality: The backlog is a graveyard of ideas.
500 items. Half are outdated. A quarter are duplicates. No one wants to say “no” so everything stays.
Result: Backlog grooming becomes an endless chore.
Problem 3: Estimates Are Fiction
Story points, velocity, sprint commitments—all guesses.
“This is a 5-point story.”
Translation: “I have no idea, but 5 sounds reasonable.”
Then the story takes 3 times longer. Or half as long. The estimate was meaningless.
Problem 4: No Appetite for Risk
Scrum assumes:
- We know what we’re building
- We just need to break it into tasks
- If we estimate well, we’ll deliver on time
Reality:
- We don’t fully understand the problem
- Unknowns emerge mid-sprint
- Scope expands
Result: Sprints fail. Teams feel like they’re constantly behind.
Problem 5: Everything Feels the Same
In Scrum: Every sprint is the same. Two weeks. Sprint planning. Daily standup. Review. Retro. Repeat.
There’s no rhythm. No variation. Just an endless treadmill.
How Shape Up Is Different
Shape Up addresses these problems with a fundamentally different approach.
The Cycle Structure
Phase 1: 6-Week Cycle (Build)
- Teams work on projects
- Fixed time: 6 weeks, no extensions
- Variable scope: Cut scope to fit time
- No interruptions, no meetings (except team’s choice)
Phase 2: 2-Week Cooldown (Breathe)
- No planned projects
- Fix bugs, refactor, explore ideas
- Breathing room
Phase 3: Betting Table (Commit)
- Leadership decides what to work on next cycle
- Not “planning.” Betting.
- “Is this worth 6 weeks?”
The Shape Up Process
Step 1: Shaping (Before the Cycle)
Who: Senior people (founders, product leads, architects)
What: Take a raw idea and give it boundaries.
Not:
- Detailed specs
- Wireframes
- Full designs
But:
- Problem definition
- Rough solution direction
- Boundaries (what’s in scope, what’s out)
- Key challenges identified
Example of a shaped pitch:
Project: Customer Onboarding Redesign
Problem:
- New users don't activate (35% drop off after signup)
- Current onboarding is 7 steps, takes 10 minutes
- Users don't understand the value before investing time
Appetite:
- 6 weeks (one cycle)
Solution:
- Reduce to 3 steps
- Show value immediately (let them try core feature before full signup)
- Use progress indicator so they see they're almost done
Rabbit Holes (Risks):
- Integration with auth system might be tricky
- Need to handle partial signups
- Email verification flow needs rethinking
No-Gos (Out of Scope):
- No redesigning the dashboard (that's separate)
- No adding social login (future project)
- No A/B testing framework (use simple toggle)
This is shaped: Enough direction to start, not so much that it’s micromanagement.
Step 2: Betting Table
Who: Small group of senior people (CEO, CTO, product lead)
What: Decide which shaped pitches to bet on.
The question: “Is this worth 6 weeks of a team’s time?”
Not:
- “Let’s put this in the backlog”
- “Maybe next sprint”
- “We’ll prioritize it eventually”
But:
- “Yes, we’re betting on this. It ships in 6 weeks.”
- “No, we’re not doing this.”
Key insight: Decisions are binary. In or out. No maybes.
There is no backlog.
Ideas that don’t get bet on die.
If they’re important, they’ll come back. If not, good riddance.
Step 3: Building (6 Weeks)
The team gets:
- A shaped pitch (the problem and rough solution)
- 6 weeks of uninterrupted time
- Full autonomy on implementation
No daily standups (unless team wants them).
No sprint planning.
No external interruptions.
Just build.
How the team works:
Week 1-2: Figure Out the Scope
- Team reads the pitch
- Explores the problem
- Identifies unknowns
- Sketches implementation approach
- No code yet (or minimal spikes)
This is when scope gets real.
The pitch said “reduce to 3 steps.” Team realizes:
- Step 2 has 3 sub-flows
- Email verification is harder than expected
- Need to handle edge cases
Team communicates: “Here’s what we’re cutting to hit 6 weeks.”
Week 3-4: Climb the Hill
Basecamp uses “Hill Charts” to track progress.
Left side of hill (Uphill): Figuring things out, exploring, problem-solving
Top of hill: Confidence, clarity on how to finish
Right side of hill (Downhill): Execution, known work
Example:
A project might have 3 scopes:
- New signup flow
- Email verification system
- Dashboard welcome message
Week 3:
- Scope 1: Climbing uphill (still figuring out design)
- Scope 2: Near top (integration approach clear)
- Scope 3: Downhill (just implementation left)
This is better than “story points” or “% complete” because it shows RISK.
If something is still uphill in week 5, that’s a problem.
Week 5-6: Finish and Polish
- Everything should be downhill by now
- Focus on finishing, not starting new things
- Cut scope aggressively if needed
The rule: If it doesn’t fit in 6 weeks, cut it.
No extensions. No “just one more week.”
Either ship it or kill it.
Step 4: Cooldown (2 Weeks)
After the 6-week cycle, teams get 2 weeks of breathing room.
No planned projects. No commitments.
What teams do:
- Fix bugs
- Refactor gnarly code
- Pay down technical debt
- Explore side ideas
- Write docs
- Learn new tools
Why this matters:
Without cooldown:
- Technical debt accumulates
- Engineers burn out
- No time for exploration
With cooldown:
- Sustainable pace
- Space to improve the system
- Engineers stay fresh
Cooldown is NOT a “catch-up” period for unfinished work.
If you didn’t finish in 6 weeks, the project is done anyway. Scope gets cut.
Key Principles
1. Fixed Time, Variable Scope
Scrum: Fixed scope, variable time (“we’ll keep sprinting until it’s done”)
Shape Up: Fixed time, variable scope (“we have 6 weeks, cut what doesn’t fit”)
Why this works:
Deadlines force prioritization. Without a true deadline, teams gold-plate features.
Example:
You’re building a customer onboarding flow.
Ideal version:
- 3 steps
- Beautiful animations
- Personalized recommendations
- Social login
- A/B testing
6-week reality:
- 3 steps (yes)
- Simple transitions (good enough)
- Generic recommendations (future project)
- Email login only (social login later)
- Simple feature flag (no A/B framework)
Ship the core. Cut the rest.
2. No Backlogs
Basecamp’s philosophy:
“If an idea is important, it’ll come back. If it’s not, it’ll fade away.”
No 500-item backlog. No grooming meetings.
How this works:
Ideas get shaped and pitched. If they don’t get bet on, they disappear.
If the idea is truly important, someone will re-pitch it next cycle.
Benefits:
- No anxiety about “all the things we’re not doing”
- No maintenance of outdated ideas
- Focus on what actually matters now
3. Betting, Not Planning
Planning implies: “We’re going to do all of these things, we just need to sequence them.”
Betting implies: “We’re committing to these specific things. Everything else is off the table.”
The shift:
From “infinite work, let’s prioritize” to “finite capacity, let’s choose.”
4. Small Teams, Big Autonomy
Team size:
- 1 designer
- 1-2 engineers
That’s it. 2-3 people.
Why small:
- Fast communication
- Minimal coordination
- High autonomy
- Clear ownership
What they own: Everything. Design, implementation, testing, shipping.
No handoffs.
5. Work Is Like a Hill
Traditional project tracking: “We’re 60% done.”
What that means: ???
Hill Charts: “We’re figuring out the integration (uphill).” “We’re executing the UI (downhill).”
This surfaces risk.
If you’re uphill in week 5, leadership knows there’s a problem.
Real-World Example
Let’s walk through a Shape Up cycle:
Pre-Cycle: Shaping
Raw idea: “Customers are confused about billing.”
Shaped pitch:
Problem:
- Support tickets about billing are 30% of volume
- Customers don't understand what they're paying for
- Billing page is confusing
Appetite: 6 weeks
Solution:
- Add clear breakdown of charges
- Show usage metrics next to billing
- Explain each line item
Rabbit Holes:
- Integration with payment provider API
- Historical data might be slow to load
No-Gos:
- No invoice redesign
- No payment method management changes
- No adding new payment options
Betting Table:
Question: “Is this worth 6 weeks?”
Discussion:
- Billing confusion is a top support issue
- Reducing tickets saves support time
- Clearer billing might reduce churn
Decision: Yes. Bet on it.
Cycle Week 1:
Team reads pitch. Explores the problem.
Discovery:
- Payment provider API has rate limits (rabbit hole identified)
- Historical data query is slow (as expected)
- Need to cache usage data
Team decides:
- Real-time usage for current month
- Cached data for previous months
- Line item explanations will be static (not dynamic)
Cycle Week 3:
Hill chart:
- Scope 1 (Billing breakdown UI): Downhill (implementation underway)
- Scope 2 (Usage metrics integration): Uphill (still figuring out caching strategy)
- Scope 3 (Line item explanations): Downhill (content written, just needs UI)
Team flags: “Caching strategy still unclear. Might need to simplify.”
Cycle Week 5:
Team cuts scope:
- Skip historical usage data (future project)
- Show only current month’s usage
- Cache expires daily (simpler logic)
Everything is downhill now.
Cycle Week 6:
Finishing touches. Ship it.
Result:
- Support tickets about billing drop 40%
- Customers understand charges better
- Team feels good about what shipped
Cooldown (2 Weeks):
Team:
- Refactors the caching logic (it works but is messy)
- Fixes a few edge case bugs
- Explores adding historical data (shapes a pitch for future cycle)
What Works Well
✅ Longer Cycles = Deep Work
6 weeks is enough time to:
- Understand the problem
- Try different approaches
- Build something meaningful
Not just “finish 5 story points.”
✅ No Backlogs = Clarity
You’re either working on something or you’re not.
No anxiety about the 500 items you’re not doing.
✅ Cooldowns = Sustainability
2 weeks to breathe prevents burnout.
✅ Hill Charts = Real Progress Tracking
“Are we figuring things out or executing?” is more useful than “We’re 60% done.”
✅ Small Teams = Speed
2-3 people can move fast. No coordination overhead.
What’s Challenging
⚠️ Not Great for Large Organizations
Shape Up works for Basecamp (50 people, 3-4 teams).
For 500 people with 50 teams, it’s harder:
- Dependencies between teams
- Longer cycles mean less coordination touchpoints
- Hard to sequence work
⚠️ Requires Strong Shapers
Shaping is a skill. It’s hard.
You need people who can:
- Define problems clearly
- Propose rough solutions
- Identify risks
- Set boundaries
If your shapers are weak, teams get vague pitches and flounder.
⚠️ Fixed Time Can Feel Harsh
“6 weeks is up. Ship or kill it.”
No extensions. No excuses.
Some teams find this motivating. Others find it stressful.
⚠️ No Backlogs Can Feel Chaotic
For people used to backlogs:
“Where do ideas go if we’re not doing them?”
Answer: They die. If they’re important, they’ll come back.
This feels scary at first.
⚠️ Not Great for Continuous Delivery
If you ship multiple times per day (like DevOps tooling), 6-week cycles feel slow.
Shape Up is better for product work than operational work.
How to Adopt Shape Up
Start Small
Don’t: “We’re switching to Shape Up! Everyone read the book!”
Do: “One team will try a 6-week cycle. Let’s see how it goes.”
Try One Cycle
Experiment:
- Shape one project (rough it out)
- Give team 6 weeks
- No interruptions
- Fixed time, variable scope
After 6 weeks:
- Retro: What worked? What didn’t?
- Adjust
Focus on the Principles, Not the Rituals
You don’t need to copy Basecamp exactly.
The principles:
- Longer cycles (reduce context switching)
- Fixed time, variable scope (force prioritization)
- No backlogs (reduce anxiety)
- Small teams (increase speed)
Adapt to your context.
Train Your Shapers
Shaping is a skill. Teach it.
Good shaping:
- Clear problem statement
- Rough solution (not detailed spec)
- Boundaries (in scope, out of scope)
- Risks flagged
Bad shaping:
- Vague (“improve the dashboard”)
- Too detailed (micromanaging)
- No boundaries (scope creep inevitable)
Key Takeaways
- 6-week cycles, not 2-week sprints - Deeper work, less thrash
- Fixed time, variable scope - Cut features to hit deadline
- No backlogs - Ideas die if not bet on
- Betting, not planning - Leadership commits to ideas worth doing
- Shaping before building - Rough outlines, not detailed specs
- 2-week cooldown - Breathing room, sustainability
- Hill charts - Track risk, not fake progress
- Small teams - 2-3 people, full autonomy
- Alternative to Scrum - Not better for everyone, but better for many
Scrum works for some teams.
But if you’re exhausted by:
- Endless sprint planning
- Meaningless estimates
- 500-item backlogs
- Two-week treadmill
Shape Up might be your answer.
It’s not perfect. It’s not universal.
But it’s a real alternative.
And for many teams, it’s better.
Give it a shot. Try one cycle. See what happens.
You might never go back to Scrum.