
Scrum vs Kanban: The Sprint vs The Conveyor Belt
Sprinting every 2 weeks (Scrum) vs Continuous flow like sushi belt (Kanban). Which one fits your team?

Sprinting every 2 weeks (Scrum) vs Continuous flow like sushi belt (Kanban). Which one fits your team?
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.

Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?

Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?

Establishing TCP connection is expensive. Reuse it for multiple requests.

Startup first day, CEO said:
"Let's do this Agile development everyone's doing!"
Me: "Great! What's that?"
CEO: "...I don't know either, but Scrum or Kanban they say."
Me: "???"
Company grew, chaos happened:
CEO: "Let's organize with Scrum!"
That's when I started studying Scrum and Kanban.When I first read Scrum documentation, my head spun:
Most importantly: "Can't we just make a To-Do list?"
Install Jira, name it "Sprint," and we're Agile, right?
Spoiler: No. That's not it.
I was confused until I came across an analogy in some documentation that clicked instantly:
"Oh! Completely different styles!"Scrum = Sprinter: "Think of a 100m dash runner. Starting gun fires → Sprint like crazy → Finish line! Rest a bit → Prepare for next race.
2-week Sprint: Monday start → Sprint until Friday → Demo! Weekend rest → Next Sprint begins."
Kanban = Sushi Belt: "Sushi flows on a conveyor belt. Customer takes one → Kitchen adds another. Never stops flowing.
Work arrives → Process → Complete More arrives → Process → Complete Endless flow."
That's when I understood. Scrum and Kanban aren't just different board tools—they're fundamentally different ways of working.
Sprint: Development in 2-week cycles (typically).
Sprint Planning (Monday):
"These 3 features for 2 weeks.
Don't disturb us with other stuff."
Daily Standup (Every morning, 15min):
"What did you do yesterday?"
"What will you do today?"
"Any blockers?"
Sprint Review (Friday):
"Demo time for completed features!"
Retrospective (Friday afternoon):
"What went well? What sucked?"
Initially I thought "Isn't this too many meetings?"
But after actually doing it, I realized this rhythm was the key: it's the metronome that keeps the team synchronized.
When I introduced it to my team:
CEO: "This feature urgent! Build now!"
Dev A: "OK... (stops current work)"
3 days later
CEO: "Progress on last request?"
Dev A: "Uh? That one? Urgent stuff came up..."
1 week later
Dev A status:
- Task 1 (40% complete)
- Task 2 (30% complete)
- Task 3 (20% complete)
- Task 4 (10% complete)
Problem: Nothing finishes. Started everything, completed nothing.
CEO: "This feature urgent!"
Scrum Master: "We're in a Sprint, can't add now.
Let's discuss priority at next Sprint Planning."
CEO: "When's that?"
Scrum Master: "Next Monday's Sprint Planning."
2 weeks later
3 features complete! ✅
Effect: Clear completion timeline. What matters isn't "how many started" but "how many finished".
Product Owner (PO):
- Role: Decides "what to build"
- "Users want this feature!"
- Manages Product Backlog priority
Scrum Master (SM):
- Role: Process guardian
- "No adding requirements mid-Sprint!"
- Removes team impediments
Development Team:
- Role: Actual development
- "Yes, we can deliver in 2 weeks"
- Self-organize work distribution
Initially I wondered "What's different between Product Owner and PM?"
Here's what I learned:
The hardest part of Sprint Planning was "How long will this take?"
At first, we estimated in hours:
"Login feature? Hmm... 3 days?"
Reality: 5 days (including testing, bug fixes)
Time estimation was consistently wrong. So I learned: Story Points approach.
Relative complexity expressed as numbers:
Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21...
1 Point: Very easy (typo fix)
3 Point: Normal (simple CRUD API)
5 Point: Complex (payment integration)
8 Point: Very complex (new auth system)
13 Point: Huge (needs breaking down)
Key idea: Instead of "3 days," say "Login is 2x more complex than Signup"
Team members simultaneously reveal cards:
PO: "Story Points for login feature?"
Developers (flip cards simultaneously):
- Tom: 5
- Sarah: 3
- Mike: 8
Discussion:
Mike: "I said 8 because of OAuth integration"
Tom: "Oh right, changing mine from 5 to 8"
This approach clicked for me: whole team agrees, so no more "am I the only one who doesn't get it?" anxiety.
Velocity = Sum of Story Points completed per Sprint
Sprint 1: 20 Points completed
Sprint 2: 18 Points completed
Sprint 3: 22 Points completed
Average Velocity: 20 Points/Sprint
Now Sprint Planning became realistic:
Before:
PO: "Do all these 10 things this Sprint!"
Dev: "That's unrealistic..."
PO: "Just work hard!"
After:
PO: "This Sprint plan: 35 Points total"
SM: "Our Velocity is 20 though?"
PO: "Oh, let's cap at 20 Points then"
2 weeks later
Completed: 5 features (20 Points) ✅
Team morale ↑↑↑
Story Points
^
20 |●
| ●
15 | ●
| ●
10 | ●
| ●
5 | ●
| ●
0 +-----------------> Day
1 2 3 4 5 6 7 8 9 10
Ideal: Straight line down
Reality: Staircase pattern (when tasks complete)
Looking at Burndown Charts, I learned:
Board: To Do → In Progress → Done
┌─────────┬──────────────┬────────┐
│ To Do │ In Progress │ Done │
├─────────┼──────────────┼────────┤
│ Task A │ Task B │ Task E │
│ Task C │ Task D │ Task F │
│ Task G │ │ │
└─────────┴──────────────┴────────┘
Looks simple, but WIP Limit is the secret sauce.
In Progress column: Max 2 items!
Dev: "Working on B and D..."
PM: "H is also urgent!"
Dev: "In Progress is full.
I'll start it after finishing B or D."
At first I thought "Won't limiting work make us slower?"
But I learned the opposite: we got faster.
Effect: Prevents bottlenecks, escapes multitasking hell
When I introduced this to the ops team:
Developer status:
- Bug #1 (40% progress)
- Bug #2 (20% progress)
- Bug #3 (10% progress)
- Bug #4 (5% progress)
PM: "Finish at least one bug quickly!"
Dev: "They're all urgent..."
1 week later:
- Bug #1 (70% progress)
- Bug #2 (40% progress)
- Bug #3 (30% progress)
- Bug #4 (20% progress)
Completed: 0 ❌
Problem: Multitasking hell. Context switching costs exploded.
WIP Limit = 1
Developer status:
- Bug #1 (100% complete!) ✅
PM: "What about Bug #2?"
Dev: "Starting it now"
3 days later:
- Bug #2 (100% complete!) ✅
Completed: 2 ✅
Effect: Completion speed ↑. Customer satisfaction ↑.
Important metrics I learned with Kanban:
Lead Time:
Request time → Completion time
"Customer's perspective"
Cycle Time:
Work start → Completion time
"Actual work time"
Example:
Bug reported: Monday 9am
Work started: Tuesday 10am
Completed: Wednesday 3pm
Lead Time: 30 hours (Mon 9am → Wed 3pm)
Cycle Time: 17 hours (Tue 10am → Wed 3pm)
Wait Time: 13 hours (Mon 9am → Tue 10am)
I understood: Long Lead Time = unhappy customers, Long Cycle Time = process problems.
Before/after comparison example:
Before WIP Limit:
Lead Time: Average 5 days
Cycle Time: Average 2 days
Wait Time: Average 3 days (waiting while doing other work)
After WIP Limit (2 items):
Lead Time: Average 2.5 days
Cycle Time: Average 2 days
Wait Time: Average 0.5 days
Result: Up to 50% Lead Time reduction!
I had lots of trial and error setting up Kanban tools. I learned: tool configuration is a skill too.
Bad:
To Do → Doing → Done
Better:
Backlog → To Do → In Progress → Code Review → Done
Best (example):
Backlog → Ready → In Dev → In Review → Testing → Done
(WIP: -) (WIP: 2) (WIP: 3) (WIP: 2)
Apply WIP Limits to each column!
JIRA Automation:
1. PR created → Auto move "In Dev" → "In Review"
2. PR merged → Auto move "In Review" → "Testing"
3. No movement for 3 days → Slack notification
This automation eliminated the "I forgot to move the card" problem.
| Item | Scrum | Kanban |
|---|---|---|
| Rhythm | 2-week Sprint cycles | Continuous (No time-box) |
| Planning | Sprint Planning (regular) | Anytime (Pull System) |
| Changes | Mid-Sprint ❌ | Anytime ✅ |
| Meetings | Daily, Review, Retro | No required meetings |
| Roles | PO, SM, Dev Team | No defined roles |
| Best for | Product development (Features) | Ops/maintenance (Bugs, Support) |
| Goal | Sprint completion | Fast throughput |
| Metrics | Velocity, Burndown | Cycle Time, Lead Time |
Sprint 1 (2 weeks):
- Login feature (8 Points)
- Signup feature (5 Points)
- Password reset (5 Points)
Total: 18 Points (Team Velocity: 20)
Sprint Planning (Monday 10am, 2 hours):
PO: "Only these 3 features!"
Devs: Agree on Story Points
Daily Standup (Every day 9:30am, 15min):
Tom: "Yesterday finished login API, today testing. No blockers"
Sarah: "Signup UI 80%, finishing today. CSS issue"
Mike: "I'll help with CSS"
Sprint Review (Friday 2pm):
Demo to CEO → "Nice!" → Get feedback
Retrospective (Friday 4pm):
Good: API documentation well done
Bad: Many CSS conflicts
Action: Consider Tailwind adoption
Result: Clear deliverables every 2 weeks. CEO satisfaction ↑.
Board:
┌──────────┬───────────┬────────┐
│ Backlog │ Doing(2) │ Done │
├──────────┼───────────┼────────┤
│ Bug #15 │ Bug #12 │ Bug #8 │
│ Bug #16 │ Bug #13 │ Bug #9 │
│ Bug #17 │ │ Bug #10│
│ Bug #18 │ │ Bug #11│
└──────────┴───────────┴────────┘
WIP Limit: 2
New bug → Add to Backlog
Bug #12 done → Move to Done
Bug #15 started → Move to Doing
Priority Lanes:
P0 (Critical): Immediate
P1 (High): Same day
P2 (Normal): Within 3 days
P3 (Low): Within 2 weeks
Result: Continuous processing, fast response. Customer complaints reduced 50%.
Sprint Day 3
CEO: "Competitor launched new feature! We need it urgently!"
Scrum Master: "We're mid-Sprint, can't add now"
CEO: "But the company is at stake?!"
SM: "..."
Solutions:
Sprint Planning
PO: "Let's build 10 features! (80 Points total)"
Dev: "80 Points in 2 weeks is impossible... Our Velocity is 20"
PO: "Just work harder!"
2 weeks later
Completed: 3 features (20 Points) ❌
Incomplete: 7 features (60 Points)
Team morale ↓↓↓
Solution: Velocity measurement + Historical Data
Sprint Planning (improved):
PO: "This Sprint goal: 80 Points!"
SM: "Recent 3 Sprint Velocities:
Sprint 1: 18 Points
Sprint 2: 22 Points
Sprint 3: 20 Points
Average: 20 Points"
PO: "OK, cap at 20 Points"
2 weeks later
Completed: 5 features (20 Points) ✅
Team morale ↑↑↑
Bad Daily Standup:
Tom (20min): "Yesterday I built login API,
during the process I had JWT token issues...
(detailed explanation 10 minutes)
So I searched Stack Overflow..."
Sarah (15min): "I had similar issues..."
Ends after 1 hour
Solution: 15-minute timer + Detailed discussions After Meeting
Good Daily Standup (15min):
Tom (2min): "Yesterday: Login API done
Today: Writing tests
Issue: JWT token problem"
SM: "JWT issue - Tom and Sarah stay after Standup"
Sarah (2min): "Yesterday: Signup UI
Today: Finishing
Issue: None"
Done in 15 minutes ✅
Board:
┌──────┬────────────────┬──────┐
│ Todo │ In Progress(?) │ Done │
├──────┼────────────────┼──────┤
│ │ Task 1 │ │
│ │ Task 2 │ │
│ │ Task 3 │ │
│ │ Task 4 │ │
│ │ Task 5 │ │
│ │ Task 6 │ │
│ │ Task 7 │ │
│ │ Task 8 │ │
└──────┴────────────────┴──────┘
Dev: "Working on all of them!"
PM: "When will they finish?"
Dev: "...Don't know"
Problem: Called Kanban but just a To-Do List. "In Progress" becomes a trash bin.
Solution: Enforce WIP Limit
Board:
┌──────┬───────────────┬──────┐
│ Todo │ In Progress(2)│ Done │
├──────┼───────────────┼──────┤
│ Task │ Task 1 │ Task │
│ Task │ Task 2 │ Task │
│ Task │ (FULL!) │ Task │
└──────┴───────────────┴──────┘
PM: "Task 3 is also urgent!"
Dev: "In Progress is full. Finishing Task 1 first"
PM: "Got it"
Clear priorities!
Backlog:
- Bug A (critical, service down)
- Feature B (CEO request)
- Bug C (typo)
- Feature D (nice to have...)
Dev: "Which one first?"
PM: "...All urgent"
Dev: "Please decide order"
PM: "Use your judgment"
Solution: Priority Lanes + SLA
┌─────────┬──────┬──────────┬──────┐
│ Backlog │ P0 │ Doing(2) │ Done │
├─────────┼──────┼──────────┼──────┤
│ Feat D │ BugA │ Bug A │ │
│ Bug C │ │ Feat B │ │
│ │ │ │ │
└─────────┴──────┴──────────┴──────┘
Rules:
P0 (Critical): Bypass WIP Limit, start immediately
P1 (High): Priority processing
P2 (Normal): Process in order
Many companies say "We do Agile!" but when you look closely...
CEO: "We do Scrum!"
Reality:
6 months upfront planning → Sprints only for implementation
Change request → "Not in the spec"
Sprint Review → Formality reporting
This is Waterfall...
Characteristics:
"We do Scrum, but..."
"We do Scrum, but Sprints are 1 month"
→ That's Mini-Waterfall
"We do Scrum, but we skip Retrospectives"
→ Then how do you improve?
"We do Scrum, but requirements keep getting added mid-Sprint"
→ That's not Scrum, that's Chaos
Daily Standup:
Tom: "Yesterday coding, today coding, no issues"
Sarah: "Yesterday coding, today coding, no issues"
Mike: "Yesterday coding, today coding, no issues"
(Nobody listening, glazed eyes, stream of consciousness)
Sprint Review:
"Demo... none. Nothing finished"
Retrospective:
"Improvements... nothing really?"
The point: Following the form but the spirit is dead.
❌ Wrong:
"Use Jira so we're Agile!"
"Do Daily Standup so we're Scrum!"
✅ Right:
"Rapidly incorporate customer feedback"
"Deploy working product every 2 weeks"
"Team self-improves continuously"
The real insight: Agile isn't about tools or processes—it's a mindset.
Scrum strengths:
- Sprint (rhythmic cadence)
- Sprint Review (demo, feedback)
- Retrospective (improvement)
Kanban strengths:
- WIP Limit (prevent bottlenecks)
- Flexible prioritization
- Visual flow
= Scrumban!
2-week Sprint + Kanban Board
Sprint Planning:
"This 2-week goal:
- Login (8 Points)
- Signup (5 Points)
- Total 13 Points (considering Velocity)"
But:
- Use Kanban Board (To Do → Doing → Done)
- Apply WIP Limit (Doing: 2 items)
- Urgent bugs can be added mid-Sprint (but adjust Sprint goal)
- Daily Standup is team's choice (we do every other day)
Keep Sprint Review + Retrospective:
- Review: Customer/CEO feedback
- Retro: Team improvement
Switching to Scrumban brings these realizations:
| Team Size | Recommendation | Reason |
|---|---|---|
| 1-2 people | Kanban | Low meeting overhead, fast decisions |
| 3-7 people | Scrum | Need coordination, Sprint effective, optimal team size |
| 8-15 people | Scrum + Multiple teams | Split into teams (5-7 each), Scrum of Scrums |
| 16+ people | SAFe/LeSS | Need large-scale framework |
Team size characteristics:
Initially I thought "Scrum vs Kanban, which is better?"
Now I understand:
"Pick what fits your team. Better yet, mix and match for your team."Lessons I learned:
Whether your Sprint is 1 week, you skip Daily Standups, or your WIP Limit is 3, what matters is "Does the team function well?"
And the key insight: The core of Agile isn't process—it's "fast feedback, continuous improvement".
What approach fits your team? Try it, retrospect, and improve.