What’s the Difference Between Scrum and Kanban?
It’s always crucial to learn all details and choose the best solution if you have two equal options. Choosing between the methods of development management is also not an easy thing, especially if it is Scrum or Kanban.
Two popular Agile methods
Scrum and Kanban are Agile-methodologies. Both are considered flexible and iterative. Before we dive into the differences between them, let’s recall what unites them.
More than 17 years ago, IT development leaders formulated the Agile Manifesto. Here’re the key points:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Basically, I agree with all these points.
- People are more important than tools. People united together and committed to the common goal will achieve more.
- Minimum viable product (MVP) approach in development. Meaning that we release minimum viable version of a product to the market asap. All out of the box features we leave for later.
- I’d change the word ‘customer’ to ‘user’. Requirements should be collected not from a customer but from future users. That was perfectly described in the book by Karl Wiegers and Joy Beatty. Lately a project is usually a startup. In the context of startups, such thing as customer development comes to mind. In fact, during customer development, we check our theories even before a prototype development. Our goal is to make sure:
- That issues, that we are trying to solve, exist in the users’ life;
- That these issues are considerable;
- That users will pay for the solution;
- That there’s a market and it’s not an isolated issue;
- That there are channels for attracting users (i.e. Facebook Ads or Google Adwords) and we will find such a price that will give us income (Customer Acquisition Cost < Lifetime Value).
- You need that point about flexibility when your UX Designer or product manager change requirements in a task and a developer is annoyed by regular changes. This is exactly when you refer to that point of flexibility. Actually, we need to get deeper. What is this willingness for updates? We need it to be able to react to feedback. Let’s say you implemented a new feature to your product, collected behavioral data, made sure that we need to change some features and start working on it. And here it is, you have upgraded version of a feature. To do all that you need to be open for changes (it’s all about agile) and the ability to catch those changes (it concerns analytics and data).
Those were the main ideas from the manifesto. There are still 12 principles but they are self-explanatory, we won’t go that far, we still have to figure out our own things in this article.
Now let’s get back to the Scrum and Kanban comparison.
Scrum vs Kanban: what should I choose?
Scrum consists of short iterations or sprints which last as a rule 2-3 weeks. A team makes a list of features for iteration and then start running a sprint. As a rule, features that are being worked on during a sprint don’t change. What was started at the beginning of the sprint must be done by its end at all costs?
Now we’ll take a look at Kanban at the place where it was created. Let’s imagine a product line which produces components for Toyota cars. Here’s a machine that makes mirrors for cars. It can make left mirrors, right mirrors, back mirrors, mirrors for sun visors and that’s enough. Press a button, change a mode and get a new product. So if someone ordered a Toyota Camry with all the feature included from a center in Houston, the product line is already working on producing mirrors for sun visors. They ordered that car because of those mirrors after all.
The most important thing here is that we can change priorities any moment. We can quickly switch a machine to the different mode.
The main difference between Scrum and Kanban is in iteration length. It lasts 2 weeks in Scrum, in Kanban you may ‘feed’ a developer with tasks every day. From my point of view, that is the main difference. Kanban is more flexible and by flexibility we mean priorities change the frequency. Yesterday you implemented a new feature, today you got information on how it works in real life and learnt that that thing doesn’t work as it was planned. People simply don’t press the Buy button. You reprimand a UX designer, they give you new requirements, you move the task up to the top in a queue. Then a developer starts working on this task and voila! a fix is production-ready by the evening, conversion rate is increased by 12%, this is a win!
In Scrum, you usually estimate tasks with Story Points or with Hours. It’s impossible to form a sprint without estimation. We need to know, will we finish all tasks in 2 weeks? After 2 weeks we get valuable statistics, how many hours or story points a team managed to complete during a sprint. This parameter lets scrum manager predict where the team will be in 2 weeks.
It’s not common to make estimations in Kanban, this is optional and the team decides by their own whether they do it or not. There’s no such thing as team velocity, you take into account only an average time for task completion. This time is counted by a special Cycle Time Report.
Task Cycle Time = Time spent working on a task – Time when the task was started.
For example, you have these columns: To Do, Reopened, Developing, Testing, Stage Testing, Deployed.
Cycle time for a task = Deployed – Developing, meaning how much time passed since the moment when the task was started until that moment when it was moved to Deployed Column.
So, our goal in Scrum is to finish a sprint but for Kanban, you need to finish a task. Scrum is a bus which stops only at particular bus stops where people hop off with groups. Whereas, Kanban is a cab which lets passengers get off whenever and wherever they need.
iCanScrumBan
What awesome things are there in a Kanban board that we’ve been using in our sprints for a long time?
WIP
First of all, WIP stands for Work in Progress. We set a limit for the number of tasks which an employee can work on at the same time. Napoleon and Caesar were famous for their multitasking skills but we all know how they ended up. We take care of our people and save them from burning out, therefore they work only on one task at one unit of time. Jokes aside research has shown it takes 15 minutes for a developer to switch from one task to another one.
You need time to make tea, to look through some articles on the web, to read requirements for a new task, to remember where you’ve paused and found that spot in the code. Switching from task to task is a leaving from a stream of thought to another and it’s not always easy to get back to that stream of thought.
Such things as external stimuli or internal thoughts that whisper to you “Chill bro, today’s Friday” may disturb your intention of going back to that stream of thought. Thus we have a strict rule – 1 task per person. How do we control it? Like this:
Swimlanes
Imagine that your website is down during working hours, obviously. Cool guys have their websites down only in working time. You assign a task to fix it immediately to your team leader or to devops engineer. And they are doing another task and are planning to finish it by lunchtime tomorrow. What do you do? Do you run to them, tap them on the shoulder and beg them to switch to a blocker? You can do it once, twice but are you willing to work that way all the time? Therefore we use Swimlanes
In this case, you have a “Blocker” Swimlane. All tasks that need a real-time solution are set in this block. Developers stop doing their current tasks immediately, pause them and start working on blocking things.
We also have a really useful swimlane that is named ‘Someday’. We put all tasks that we will likely do one day under that block. This really helps us to set aside all unnecessary things so people could focus on the important tasks. As a rule, those someday tasks stay in that swimlane forever. ‘The right’ testers find many ‘right’ bugs and all of them go to developers. If you don’t check those bugs and leave them in the main queue of tasks then you will realize sooner or later that developers are working on some unimportant stuff. That’s why each team should have a person or better yet, a few people who understand which bugs are critical and which ones should go straight to Someday.
Sub-columns
You have a column named ‘Coding’ and right after it one that says ‘Testing’. When developers finish their task they drag it to ‘Testing’. It seems like testers sort of started working on a task already, but in fact, they are doing another one. And after all, you’ve already set a WIP limit for the number of tasks. Once developers move a task for testing, they disturb that limit for QA, now there are two tasks already. Alarm! Let’s say developers won’t drag their task to the ‘Testing’ column and will leave in the ‘Coding’ one. But how can they take next task if they have a WIP limit which they can’t break? In this case, sub-columns are the solution. For example, we make sub-column ‘In Progress’ and ‘Done’ for ‘Coding’ column. So when developers finish their tasks, they move them to ‘Done’ sub-column. When testers are free, they will take another new task from ‘Done’ sub-column of ‘Coding’ column to the ‘Testing’ column.
Conclusion
In conclusion, I’d like to say that scrum is a flexible development methodology but Kanban is even more flexible. Everything has its own purpose. It’s better to use scrum at the beginning of product development as it’s easier to manage deadlines with scrum. Also, there’s a lot of communication in the team, they discuss all Backlog sprint before the start. They ask questions to tasks creators (UX designer, product managers, business analytics). The team estimates tasks together using planning poker. Scrum helps a team to understand a core of the product.
But after you launch the product, that’s another story. You start receiving feedback from users and you need to react to it quickly. You start working with Hypothesis Action Data Insight (HADI) cycles as you need to check different theories since sometimes even a button color may affect those theories. You start measuring and optimizing product metrics. For example, Pirate Metrics AARRR (Acquisition, Activation, Retention, Revenue, Referral) and so on. Everything breaks your development cycle into smaller units and you start doing many small tasks in unpredictable order. Kanban is perfect for it.
Do you have your own experience with Kanban and Scrum? Feel free to add comments here.