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:
- If truly critical, abort Sprint (Sprint Abnormal Termination)
- Discard Sprint and start fresh
- But: Team morale ↓, don't abuse
- 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.