Scrum vs Kanban: The Sprint vs The Conveyor Belt

Prologue: "Should we do Agile too?"

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: "???"

Why I Studied This

Company grew, chaos happened:

• Problem 1: "When's this feature done?" → Nobody knows
• Problem 2: Each dev juggling 10 tasks simultaneously → Nothing finishes
• Problem 3: Urgent bug appears → Who fixes it?

CEO: "Let's organize with Scrum!"

That's when I started studying Scrum and Kanban.

What Confused Me Initially

When I first read Scrum documentation, my head spun:

• What's the difference between Scrum and Kanban?
• What's a Sprint? Not a marathon?
• Why Daily Standup? Meeting every day?
• What's WIP Limit? Won't limiting work slow us down?

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.

The Aha Moment: "Sprinter vs Sushi Belt"

I was confused until I came across an analogy in some documentation that clicked instantly:

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."

"Oh! Completely different styles!"

That's when I understood. Scrum and Kanban aren't just different board tools—they're fundamentally different ways of working.

1. Scrum: 2-Week Sprint Cycles

Core Concept

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.

Real Experience

When I introduced it to my team:

Before Scrum

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.

After Scrum

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".

Scrum Roles

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:

• PM: Project management (timeline, resources, risk)
• PO: Product value maximization (what and why to build)

Story Points: My Learning Experience

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.

What are Story Points?

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"

Planning Poker

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: Measuring Team Speed

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 ↑↑↑

Burndown Chart: Visualizing Progress

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:

• Chart stays flat: Work not getting done → Need help
• Chart drops sharply: Tasks completing → Going well
• Chart goes up: Scope added → Warning!

2. Kanban: Continuous Flow

Core Concept

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.

WIP Limit (The Core!)

WIP = Work In Progress

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

Real Experience

When I introduced this to the ops team:

Before Kanban

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.

After Kanban

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 ↑.

Cycle Time vs Lead Time

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!

JIRA/Linear Setup Tips

I had lots of trial and error setting up Kanban tools. I learned: tool configuration is a skill too.

Column Design

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!

Automation Rules

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.

3. Scrum vs Kanban Comparison

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

4. Real Case: Scrum Implementation

Product Team (5 people)

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 ↑.

5. Real Case: Kanban Implementation

Customer Support Team (3 people)

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%.

6. Scrum Pitfalls

Pitfall 1: Mid-Sprint Urgencies

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:

1. If truly critical, abort Sprint (Sprint Abnormal Termination)
   • Discard Sprint and start fresh
   • But: Team morale ↓, don't abuse
2. Prioritize for next Sprint
   • Realistically, this is Best
   • 99% of "urgent" can wait 2 weeks

Pitfall 2: Unrealistic Goals

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 ↑↑↑

Pitfall 3: 1-Hour Daily Standups

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 ✅

7. Kanban Pitfalls

Pitfall 1: No WIP Limit

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!

Pitfall 2: Priority Confusion

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

8. Agile Anti-Patterns: "Fake Agile"

Many companies say "We do Agile!" but when you look closely...

Anti-Pattern 1: Agile-fall (Waterfall in Agile clothing)

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:

• Sprints exist but planning finished 6 months ago
• "Agile" but no changes allowed
• Daily Standup becomes progress report meeting

Anti-Pattern 2: Scrum-but

"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

Anti-Pattern 3: Zombie Scrum

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.

What Real Agile Looks Like

❌ 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.

9. Hybrid: Scrumban

Scrum strengths:
- Sprint (rhythmic cadence)
- Sprint Review (demo, feedback)
- Retrospective (improvement)

Kanban strengths:
- WIP Limit (prevent bottlenecks)
- Flexible prioritization
- Visual flow

= Scrumban!

Real Usage

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:

• Scrum's rhythm: Never lose direction
• Kanban's flexibility: Handle urgent items

10. Team Size Recommendations

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:

• 2-person team (early): Kanban fits well. Daily Standup? Sitting next to each other makes it unnecessary.
• 5-person team (growth): Scrum makes sense. Now coordination needed. Sprint creates rhythm.
• As teams grow larger: Split into multiple teams. Each does Scrum. Weekly full team Sync recommended.

11. Summary: Selection Guide

Choose Scrum (If...)

• ✅ Developing new product
• ✅ Need clear milestones (funding, launch)
• ✅ Want team rhythm (many juniors)
• ✅ Need regular demo/feedback (many stakeholders)
• ✅ Team size 3-7 people

Choose Kanban (If...)

• ✅ Ops/maintenance work (Ops, Support)
• ✅ Requirements change frequently (early startup)
• ✅ Continuous deployment environment (DevOps, SaaS)
• ✅ Hate meetings (solo, small team)
• ✅ High priority volatility

Choose Scrumban (If...)

• ✅ Scrum too rigid
• ✅ Kanban lacks direction
• ✅ Want best of both worlds
• ✅ Mature team (high autonomy)

Final Thoughts: "Tools are Just Tools"

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:

• Scrum: Sprint like a runner → Clear results, periodic improvement
• Kanban: Flow like sushi belt → Fast response, visual management
• Can mix: Scrumban for best of both worlds

"Don't follow blindly—adapt to your team"

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.