In the last post, we did a deep dive into Agile and Lean project management, covering their origins, history, and practical applications. At the end of the day, every principle, board, and rule shares the same goal: superior project management. But you cannot effectively manage what you do not understand. That is why today’s post focuses on Kanban and Scrum.
Many teams around the globe are drowning in tickets and watching their Sprints crash; consequently, they are turning to an ‘Agile transformation.‘
In short, both Scrum and Kanban are tools that are designed to solve specific problems regarding how human beings organize complex work. To understand which one fits your needs, we have to strip away the marketing fluff and look at the mechanics of how they function, where they break, and why they exist in the first place. In the end, all of us want to deliver value to customers without burning out the people doing the work.
Agile is not a methodology; it is a philosophy. That means you cannot “do” Agile. You can only “do” a framework that embodies Agile principles. This is where Scrum and Kanban enter the picture. They are the tactical execution of the Agile strategy.
What are Scrum and Kanban then? In the simplest terms, Scrum is about structured iteration. It provides a rigid skeleton of roles and events to force predictability in an unpredictable world. Kanban, on the other hand, is about continuous flow. It provides a visual management system to optimize the speed and efficiency of value delivery without necessarily changing the underlying process immediately.
In the early 90s, Jeff Sutherland and Ken Schwaber came up with a new and better way to build software: Scrum. The rationale behind Scrum was simple: You cannot plan perfectly because software development is complex and, more importantly, unpredictable. In the process, requirements change hourly and stakeholders always want “one more feature.” To handle this, Scrum draws a line in the sand called the Sprint
Sprints typically last 1 to 4 weeks. Aligned with Parkinson’s Law, which states that “work expands to fill the time available for its completion.” By artificially constraining the time available, Scrum forces the team to focus, prioritize ruthlessly, and make difficult trade-off decisions early. The Sprint also serves to limit the cost of failure. The cost of a mistake in Scrum is the length of one Sprint.
Pros
Cons
“Kanban” is Japanese for “visual signal” or “signboard”, and its first use wasn’t in software development. It started on the factory floor of Toyota.
Kanban is less of a rigid framework and more of a management method. It doesn’t tell you how to develop software (it doesn’t prescribe roles like Scrum); it helps you visualize how you are working today so you can optimize it tomorrow.
While Scrum prescribes a specific structure, Kanban is defined by a set of principles and practices focused on flow. It treats the software development process as a pipeline. The goal is to maximize the throughput of value through that pipeline.
Boards
You cannot manage what you cannot see. In manufacturing, you can see the pile of steering wheels waiting to be installed. In knowledge work, the “inventory” is invisible. It’s code inside a repository, ideas inside a designer’s head, or tickets in a database. Kanban forces this work onto a board, physical or digital board.
A basic board has “To Do,” “Doing,” and “Done.” But a real Kanban board reflects the actual complexity of the process: “Backlog,” “Analysis,” “Dev,” “Code Review,” “Testing,” “Deployment,” “Done.”
Limit Work in Progress
Limiting Work in Progress (WIP) is the most powerful aspect of Kanban. Most teams believe that to get more done, they need to start more work. Kanban argues the opposite: Stop starting, start finishing.
By placing a hard limit on the number of cards allowed in a specific column (e.g., “Max 3 items in Testing”), you force the team to focus.
The goal of Kanban is to move cards from left to right as smoothly and quickly as possible. We measure this using metrics like Lead Time (time from request to delivery) and Cycle Time (time from starting work to delivery). The focus is not on “how busy is the team?” (resource utilization) but on “how fast is value moving?” (flow efficiency).
In Scrum, the rules are in the Scrum Guide. In Kanban, the team writes their own rules and posts them on the board. So, teams can answer questions like ‘’Who is allowed to pull from the backlog?” or ‘’When is it okay to move a ticket back?”
Kanban does not mandate specific meetings like Scrum, but it requires feedback loops. These are often called “Cadences.” These are scheduled based on need, not a rigid calendar.
Pros
Cons
Now that we have established the baselines, let’s look at the direct comparison of Kanban and Scrum.
Scrum is fixed length Sprints, usually 1-4 weeks. Kanban is continuous flow.
For Scrum, typically at the end of a Sprint. For Kanban, whenever an item is ready.
Scrum is prescriptive, requires positions like PO, Scrum Master, and Developers. But Kanban does not prescribe roles.
Scrum, velocity, especially Story Points per Sprint. For Kanban, it is Cycle Time and Lead Time.
Scrum discourages scope change to protect the Sprint Goal. Kanban welcomes change as long as capacity exists.
If you are using Jira (and let’s be honest, who isn’t), the distinction between Scrum and Kanban manifests most visibly in the Board. This is where the abstract concepts become real on a screen.
A Scrum Board in Jira is a temporary artifact. It relies on the “Sprint” entity.
The Scope: It shows only the work committed to the current active Sprint. The vast backlog is hidden in a separate view/tab.
The Goal: The goal is to clear the board. An empty board at the end of the Sprint is a victory.
The Workflow: Typically “To Do,” “In Progress,” “Done.” While you can add more, the focus is usually on status relative to the Sprint end date.
Reporting: It drives the Burndown Chart (work remaining vs. time) and Velocity Chart (points completed per sprint). These are “batch” metrics.
A Kanban Board is persistent. It is a river that never dries up.
For many teams, the choice between Scrum and Kanban is a dilemma. Why choose between structure and flow when you can have both? Enter Scrumban.
Scrumban is not just “Scrum with a Kanban board.” It is a deliberate methodology that originated as a way to transition teams from Scrum to Kanban, but evolved into a standalone framework.
Scrumban takes the structure of Scrum (roles, meetings) and applies the flow principles of Kanban (WIP limits, visualization, pull system). It is the sweet spot for teams that need the “heartbeat” of Scrum but the flexibility of Kanban.
In the end, whether you call it Scrum, Kanban, or “Agile-ish,” the goal is the same: deliver value to customers faster and with higher quality. Don’t get hung up on the purity of the framework. Try, analyze and always push for a better process.