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.

Choose the agile framework that works best for your team and ONLY your team. Don’t do kanban
because that’s what Kelly from cOolStarTup.io does. Don’t do scrum because management wants to,
“Go agile.” Be ruthless and selfish in this choice. Your team will thank you.

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.

  Scrum Kanban

Regular fixed length

Cadence Continuous flow
sprints (ie, 2 weeks)

At the end of each

Continuous delivery or
Release methodology sprint if approved by
at the team's discretion
the product owner
  Scrum Kanban

Product owner, scrum No existing roles. Some

Roles master, development teams enlist the help of
team an agile coach.

Key metrics Velocity Cycle time

Teams should strive to

not make changes to
the sprint forecast
Change can happen at
Change philosophy during the sprint. Doing
any time
so compromises
learnings around
estimation.

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 its 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 Cadence

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.  

Release Methodology

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 Roles

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

Key Metrics

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.

Change Philosophy

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 Cadence

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.  

Release Methodology

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.

Kanban Roles

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.

Key Metrics

Cycle time is an important metric for kanban teams. It is the average amount of time that it 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.

Change Philosophy

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?

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