The first step in your agile transformation is deciding what agile framework works best for you and your team. Agile is a set of ideals and principles that serve as our north star. Kanban and scrum are frameworks. They’re built on the agile principles and describe how you and your team collaborate, learn, and get stuff done.
When deciding between scrum and kanban, know that you’re in good company. Kanban and scrum are two of the most popular agile frameworks and have proved their worth at thousands of companies for nearly two decades. But don’t get stars in your eyes just yet. Kanban and scrum aren’t the only options. There’s SAFe, Scrumban, Kanplan, and Atlassian’s own Agility project.
So, where were we?
Agile is a structured and iterative approach to project management and product development. It recognizes the volatility of product development, and provides a methodology for self-organizing teams to respond to change without going off the rails. Today, agile is hardly a competitive advantage. No one has the luxury to develop a product for years or even months in a black box. This means it’s more important than ever to get it right.
Kanban is all about continuous development and delivery, tackling a small number of tasks fluidly and concurrently. Kanban teams use a visual planning tool—the kanban board—that displays each project (user story) on a card and moves cards through columns that represent progressive stages of completion. If your team has a continuous stream of work requests, kanban may be right for you.
Scrum also splits out complex tasks into user stories and visualizes them on a workflow. Scrum teams commit to ship working software at the end of set intervals, called sprints. If you need to ship value to customers on a regular basis, scrum is the way.
Agility is something different all together. Agility is a clean, un-opinionated agile board that progressively adds more structure when you need it. If you can’t decide between scrum and kanban, go with an agility project.
|Cadence||Regular fixed length sprints (ie, 2 weeks)||Continuous flow|
|Release methodology||At the end of each sprint if approved by the product owner||Continuous delivery or at the team's discretion|
|Roles||Product owner, scrum master, development team||No existing roles. Some teams enlist the help of an agile coach.|
|Key metrics||Velocity||Cycle time|
|Change philosophy||Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation.||Change can happen at any time|
Scrum: A structured agile approach
Is scrum right for you? The first question to answer is this: Is your entire development team committed to just this team and it’s work, or other teams and other work too?
With scrum, your team promises to ship some valuable increment of work at the end of each sprint. If you have developers that can’t make that commitment, or are routinely pulled into other, unrelated streams of work than you’re better off not making those commitments at all and scrum may not be for you. Here are some more considerations:
Scrum moves fast, with sprints of two to at most four weeks with clear start and finish dates. The short time frame forces complex tasks to be split into smaller stories, and helps your team learn quickly. Your question is this: Can your team ship useable code that fast?
Sprints are punctuated by the sprint planning, sprint review, and retrospective meetings and peppered with the daily scrum(standup) meeting. These scrum ceremonies are lightweight and are basically a requirement. If you can’t fit four more meetings into your team’s schedule, than don’t bother.
During the sprint review, the team views a demo of the increment (the end-product of a sprint) and either approves it for release, or doesn’t. There needs to be a potentially shippable increment at the end of the sprint. There are no ad hoc releases in scrum; the team either releases at the end of a sprint cycle, or doesn’t at all.
Scrum has three clearly defined roles.
- The Product Owner owns and manages the product backlog, understands business requirements, and prioritizes the work to be done by the development team.
- The Scrum Master is manages the scrum board and workflow, and helps the team stay grounded in the scrum framework.
- The development team completes the work and demonstrates collective accountability.
Who manages the scrum team? Well, nobody. Scrum teams are self-organizing and everyone is equal, despite having different responsibilities. There is a healthy tension between competing interests and a unifying goal of shipping value to customers.
Velocity—the number of story points completed in a sprint—is the central metric for scrum teams. It guides future sprint commitments, or how much work the scrum team commits to. If the team completes an average of 35 story points(Velocity = 35), it won’t agree to a sprint backlog that contains 45 points.
Teams strive to not make scope changes during a sprint. Scrum teams sometimes get feedback and learn that what they’re working on isn’t as valuable to the customer as they thought. In such cases, the scope of the sprint should change to reflect the importance of shipping value to the customer first and foremost. During the sprint retrospective, scrum teams should discuss how to limit change in future, as changes put the potentially shippable increment at risk.
For more on scrum methodologies see What Is Scrum?
Kanban: Continuous Improvement, Flexible Processes
If you answered “No” to scrum, you’ll likely say “Yes” to kanban. First, consider your team’s control over what you work on. Kanban is great for teams that have lots of incoming requests that vary in priority and scope. Whereas scrum processes require high control over what is in scope, kanban let’s you go with the flow. Let’s take a look at the same five considerations to help you decide.
Kanban is based on a continuous workflow structure that keeps teams nimble and ready to adapt to changing priorities. Work items—represented by kanban cards— go from one stage of the workflow to the next until they are marked as Done. Common workflow stages are To Do, In Progress, In Review, Blocked, and Done. But that’s boring.
The best part of Kanban is making custom columns for how your team works. My team ships content, so our columns(simplified) go from Backlog, to Prioritized, to Outlines Ready, to Writing, Designing, Technical Review, and Shipped. We don’t have a set cadence, but we’ve learned that we ship about one piece of content per week.
In kanban, updates are released whenever they are ready, without a regular schedule or predetermined due dates.
In theory, kanban does not prescribe a fixed time to deliver a task. If the task gets completed earlier (or later), it can be released as needed without having to wait for a preset release milestone, as in the case of scrum.
The whole team owns the kanban board. Some teams enlist an agile coach to keep things moving as needed, but, unlike scrum, there is no single “kanban master” who keeps everything running smoothly. It’s the collective responsibility of the entire team to collaborate and deliver the tasks on the board.
Cycle time is an important metric for kanban teams. It is the average amount of time that takes for a task to move from the start to finish line. Improving cycle times indicates the success of kanban teams.
Cumulative Flow Diagram (CFD) is another analytical tool used by kanban teams to understand the number of work items in each state. CFD helps identify specific bottlenecks that need to be resolved for better throughput.
Another way to deal with bottlenecks is through Work In Progress(WIP) limits. A WIP limit caps the number of cards that can be in any one “stage” at one time. When you reach your WIP limit, the team swarms on those items to move them forward.
A kanban workflow can change at any time. New work items can get added to the backlog and existing cards can get blocked or removed all together based on prioritization. Also, if the team capacity changes, WIP limit can be recalibrated and work items adjusted accordingly. It’s all about being flexible in kanban.
For more on kanban methodologies see What Is Kanban?
Scrum and kanban are “agile by-the-books.” They work in a tried and true fashion that is quite frankly hard to argue against. Borrowing from another famed catch-phrase, you might say that, “No one gets fired for choosing scrum.”
For those of us whom scrum and kanban are not the best fit, there’s the agility project in Jira Software. Instead of a framework that conforms to agile principles first and foremost, agility conforms to you, with built-in guardrails to keep you agile. You build your own workflow by creating and moving columns, adding issues inline, and customizing your board.
Instead of implementing all of the framework on day one, agility allows you to layer on more and more powerful features, taking the best from both scrum and kanban. As such, no two Agility projects are the same, and so you can’t compare agility to scrum apples to apples. What you can do, is try it out.
Kanban vs Scrum vs Agility: Which framework to choose?
Regardless, choose one and stick with it, at least for a little while. We recommend running a whole sprint cycle if using scrum, or for as long as it takes to ship a few cards with your kanban board. Then, hold a retrospective and ask what went well and what went poorly.
Here are some closing thoughts:
- Choose scrum if your development team can devote 100% of their time to your project and it’s important to ship value to customers on a regular basis.
- Don’t choose scrum if it’s not the best possible fit for your team.
- Choose kanban if you value flexibility more than you value predictability and if your work maps nicely to a workflow.
- Don’t choose kanban if it’s not the best possible fit for your team.
- Choose Agility if you value the agile principles but neither scrum nor kanban is a perfect fit.