Introduction: Why Agile Frameworks Matter
Imagine you are in charge of a kitchen. You have chefs chopping vegetables, cooks stirring pots, and waiters running orders. Everyone is busy. But food is coming out late. Some dishes are cold. Customers are unhappy.
You need a system.
Not a complicated system with thick manuals. Just a simple, clear way to organise the work so everyone knows what to do, when to do it, and how to do it better tomorrow.
This is why Agile frameworks exist.
Agile is the idea, described in the Manifesto for Agile Software Development, that you should build things in small pieces, collaborate closely with customers, respond to change instead of resisting it, and improve continuously.
Scrum and Kanban are two of the most popular ways to put that idea into practice.
They are different. But both work.
This guide explains Scrum and Kanban in plain language. No jargon. No complicated theory. Just practical explanations and real examples.
What Is Scrum? (The Rhythm Method)
Scrum was developed in the early 1990s by Ken Schwaber and Jeff Sutherland.
The name comes from a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka, which compared high-performing product teams to a rugby scrum—players moving forward together as one unit.
The core idea of Scrum is simple: work in short, fixed cycles called Sprints (one month or less). At the end of each Sprint, you must have something usable to show.
The Three Accountabilities
In the current Scrum Guide, Scrum defines three accountabilities (not “roles”):
1. The Product Owner
One person. Not a committee.
Their job is to maximise product value by deciding what is most important to build next.
They manage the Product Backlog — the ordered list of work. They talk to customers and stakeholders and make priority decisions.
The team does not guess what to build. The Product Owner decides what is most valuable.
2. The Scrum Master
The coach.
Not the boss.
Their job is to help everyone understand and apply Scrum effectively. They remove impediments, foster healthy team dynamics, and protect focus.
A strong Scrum Master helps the team become self-managing and cross-functional.
3. The Developers
The people doing the work—engineers, designers, testers, analysts, writers.
In Scrum, they operate as one team. No sub-teams. No handoffs between silos. They collectively own delivering a usable Increment each Sprint.
The Five Events (The Heartbeat of Scrum)
Scrum defines five events. The Sprint is the container for all the others.
1. The Sprint
A fixed-length cycle of one month or less.
During the Sprint:
- The Sprint Goal does not change.
- Quality does not decrease.
- Scope may be clarified and adjusted as more is learned—but only if it does not endanger the Sprint Goal.
2. Sprint Planning
At the start of the Sprint, the team collaborates to define:
- Why is this Sprint valuable? (Sprint Goal)
- What can be delivered?
- How will the work get done?
They forecast what they believe they can complete—it is not a rigid contract but a professional commitment.
3. Daily Scrum
A 15-minute event for the Developers.
Older versions of Scrum promoted the “three questions” format. The current guide does not require that structure.
Instead, the Daily Scrum focuses on one thing:
How are we progressing toward the Sprint Goal?
The team adapts its plan for the next 24 hours.
The Traditional Daily Scrum
Every morning, 15 minutes. Standing up. No chairs.
Three questions:
- What did I do yesterday?
- What will I do today?
- Is anything blocking me?
This is not a status report for management. It is the team talking to itself.
4. Sprint Review
At the end of the Sprint, the team demonstrates the working Increment to stakeholders.
Not slides. A real product.
Feedback is gathered. The Product Backlog may be adjusted based on what was learned.
5. Sprint Retrospective
The team inspects how they worked together.
They discuss:
- What went well?
- What didn’t?
- What should we improve?
Then they commit to at least one meaningful improvement for the next Sprint.
Small improvements. Every Sprint.
The Three Artifacts
Scrum defines three artifacts, each with a commitment.
1. Product Backlog
Commitment: Product Goal
A living, ordered list of everything that might improve the product. It evolves constantly.
2. Sprint Backlog
Commitment: Sprint Goal
The Developers’ plan for achieving the Sprint Goal.
Important clarification:
The Sprint Backlog can evolve during the Sprint as more is learned. What must remain stable is the Sprint Goal.
3. Increment
Commitment: Definition of Done
The sum of completed work.
At the end of every Sprint, the Increment must be usable and meet the agreed Definition of Done. Not 90% finished. Done.
Scrum in Practice: A Real Example
A mobile app team works in two-week Sprints (a common but not mandatory length).
They define a Sprint Goal:
“Enable users to track daily water intake.”
During the Sprint, they adjust tasks as they learn more—but the goal remains steady.
At the Sprint Review, stakeholders test the feature. Feedback leads to new Product Backlog items.
In the Retrospective, the team decides to strengthen automated testing next Sprint.
One improvement. Every Sprint.
That is Scrum.
What Is Kanban? (The Flow Method)
Kanban originated at Toyota in the late 1940s as part of what became the Toyota Production System.
Inspired by supermarket restocking systems, Toyota introduced visual signals (“kanban” cards) to manage inventory and reduce waste.
In knowledge work, the Kanban Method was later popularised by David J. Anderson.
The core idea: Visualise work. Limit work in progress. Improve flow continuously.
The Four Principles
- Start where you are
- Agree to pursue incremental, evolutionary change
- Respect current roles and responsibilities
- Encourage leadership at all levels
Kanban does not require restructuring teams or redefining job titles.
The Six Practices
- Visualise the workflow
- Limit Work in Progress (WIP)
- Manage flow (measure and improve lead time)
- Make policies explicit
- Implement feedback loops
- Improve collaboratively, evolve experimentally
Kanban does not prescribe mandatory roles or events—but it strongly encourages regular feedback and review discussions.
Key Differences Between Scrum and Kanban
| Scrum | Kanban |
| Fixed-length Sprints (≤ 1 month) | Continuous flow |
| Sprint Goal provides focus | Work pulled when capacity allows |
| Scope stabilised around Sprint Goal | Scope can change anytime |
| Three defined accountabilities | No required roles |
| Five defined events | No mandatory events |
| Velocity sometimes used for forecasting | Lead time used to measure flow |
| Planning in batches (Sprints) | Continuous replenishment |
Important note:
Velocity in Scrum is optional and used for forecasting, not measuring productivity.
Can Scrum and Kanban Be Combined? (Yes—Scrumban)
Scrumban is not an official framework. It is a hybrid approach.
Common patterns include:
- Using Sprints but visualising work with a Kanban board and WIP limits
- Keeping a Product Owner and backlog but using continuous flow instead of fixed commitments
- Holding Reviews and Retrospectives while managing day-to-day flow with WIP limits
It is pragmatic, not dogmatic.
Conclusion: Choosing the Right Framework
Scrum and Kanban are not religions.
They are tools.
Choose Scrum when:
- You are building a defined product
- You benefit from rhythm and structured feedback
- You can deliver value in short cycles
Choose Kanban when:
- Work arrives unpredictably
- You need flexibility
- You are running ongoing operations
- You want to improve flow without restructuring
Start simple. Inspect. Adapt.
That is the real Agile mindset.
Related Post: