Detailed Comparison of Kanban vs Scrum vs Agile
Do you want to complete your projects efficiently, in time? Are you stuck on a complex project? Circling around in a fast paced and ever-changing environment? Did someone tell you to follow an agile methodology to end all these hiccups?
When it comes to an agile methodology, different people have different sets of opinions. Some say, Kanban; some say, Scrum. There you go! Another confusion.
Well, this post is to eliminate the confusion.
We are going to talk about Kanban and Scrum in this topic of ours. We will see what the Kanban framework is, what the scrum is and how they are so different from each other.
Kanban Vs Scrum Vs Agile
Table of Contents:
What is Kanban?
- To start, Kanban means “Visual Signal” in Japanese. The Kanban process is all about visualizing what you are doing today.
- The Kanban process is nothing but a Board, named as the “Kanban Board” which not only plays a significant role in displaying the workflow but also helps to optimize the flow of tasks between different teams.
- Currently, there are companies that follow physical boards and there are ones that follow virtual boards. The latter comes in handy in terms of availability and accessibility in terms of locations.
- Kanban boards basically have three segments: To Do, In Progress and Done.
- However, depending on the project, team size and workflow, Kanban boards can be mapped accordingly. The board can have modified segments such as: To Do, In Progress, Code review, In Testing, Deliverable etc.
- Every work item on the board is a Kanban Card. The only aim of using a Card [Physical/Virtual] is to make the team able enough to track the work visually.
- Cards give a brief idea on the particular work item, responsibility, estimated completion, and the current status of the work item.
- This enables the team to foresee challenges, faster capture of Blockers, increase traceability, and reduce dependencies.
- In this process, the team is only involved in the work item that is in progress. Only when the work item is moved to DONE state, they pick the next work item from the Backlog/to do list.
- The most important work items are kept at the top of the “to-do” list by the product owner. There can be reshuffling done on priority if needed.
- No fixed length iterations were followed in Kanban. It is all based on cycle times. Cycle time is the time that is needed to move a work item from To Do state through the state of the world.
- Kanban also gives importance to overlapping skill sets. When a resource has multiple skill sets, she/he doesn’t have to work on a specific skill set all the time. She/he can contribute to the work item in multiple dimensions. For e.g. a developer does not always have to stick to development. If required, he can switch to Testing which will ultimately reduce the dependencies and hence the cycle time.
What is Scrum?
- Like Kanban, Scrum is another framework for implementing Agile. Scrum is unique in having characters such as; defined iteration durations, role based tracking/approach etc.
- Scrum follows a set of fixed length iterations in which the product is developed. Each of these iterations is called Sprint. Typically, each sprint is fixed somewhere within 2 weeks to 1 month.
- The start of each Sprint happens with a Sprint Planning meeting which finalizes the backlog/work items planned for that sprint. An estimation of Sprint is also declared/justified in this phase.
- Selection of Product Backlogs for this specific Sprint is done in this phase.
- Communicate with all the involved people about the scope and completion targets.
- Backlog items can also be split when needed.
- Priorities can be modified on the backlog items in this phase and a call is taken based on it.
- Each Sprint goes on with Daily Stand-Up Meetings/Daily Scrum meetings
- Each team member will join this meeting
- This does not exceed 15 minutes.
- What has been done since the last meeting and what is to be done before the next Scrum meeting is discussed during these meetings
- Blockers, bottlenecks and dependencies, if any, are brought to notice in these meetings.
- Each Sprint event concludes with a Retrospective meeting
- Completed work items are showcased/ Demo is given on the work items
- Two things are analyzed: Success points in Sprint and the improvement area for the next Sprint.
- Once Sprint is over, repeat the same steps repeatedly for the remaining Backlog items.
- Scrum is basically operated based on the roles. Three roles to be precise: Product Owner, Scrum master, and the Development team
- Product Owner: They are the ones who know about the Product. List of Backlogs put together by them. They study real business and make sure product deliverables are best suited to address business needs.
- Scrum Master: These are the hounds who live on delivery flow, sprint planning, reviews, daily meetings etc.
- Development team: They are working towards delivering a shippable product at the end of Sprint. This team does the work such as; analyzing, designing, developing, testing, documenting etc.
Now that we know what Kanban and Scrum are individually, we can proceed to the comparison/versus question.
Kanban Vs Scrum
As we have seen in the above descriptions, both of them share the same [mostly same] ideology. But the way things are done in both of these processes is very different.
| Scrum | Kanban |
|---|---|
| The iterations/Sprints are fixed in duration. That normally varies from 2 weeks to 1 month. | This does not work on the duration. This is measured in terms of Cycle times. |
| Team basically estimates or plans each sprint based on the Backlog sheet. | This is tracked in terms of the Workflow/Work item/Kanban card |
| This process floats on the basis of three roles; The Product Owner The scrum master And the Development | This doesn’t work on the basis of roles. |
| No changes are allowed once the Sprint has started | This is flexible here. Changes are allowed at any moment |
| As Sprint is done in batches, the total work is done/achieved in batches/Sprints | Work is done based on the movement of single threaded work item flows |
Some companies/teams choose Scrum where others choose Kanban. Sometimes, both are combined together which is hailed as Scrumban. The best of both are chosen in Scrumban.
For e.g. Fixed lengths Sprint cycles and roles from Scrum with a focus on work in progress limits and cycle time from Kanban. All I am saying is, both are robust in their own way and can also be tweaked/combined together if needed. It is all up to the team/company/requirement.
What about Scrum vs Agile?
What is the difference between Scrum and Agile?
Wondering about the differences between Scrum vs Agile or Agile vs Scrum is like seeking for the differences between the words “Red” and “Color”. Red is a type of color and use of it depends on the specific taste and comfort level of their users. The same could be said about Scrum vs Agile.
Scrum is a type of agile methodology. It is essentially an agile process framework. Scrum and Kanban in software development terms are both specific flavors or types of an agile software methodology.
While we can compare Scrum vs Kanban or Kanban vs Scrum (just like we can compare the colors “Red” and “Blue”) as we’d be comparing two agile methodologies, however comparing Scrum vs Agile would be like comparing the words “Red” and “Color”.
Scrum is just one of the many iterative and incremental agile software development methods. You can find here a very detailed description of the process here.
Conclusion
There is a significant difference between Kanban and Scrum agile methodologies. Hope we are able to explain the difference in simple words.
About the author: Subhasis has over 8 years of corporate experience working for Fortune 500 IT companies in the field of Software Quality Assurance, Software Development and Testing experience. He currently heads the QA team of a top-tier IT company and loves to write about his experiences on Software Testing Tricks and here on Software Testing Help.
If you have any queries about Kanban and Scrum methodologies, let us know in the comments.
“No changes are allowed once the Sprint has started”
I have often observed that some stories are tough to implement in the same sprint cycle due to technicalities, what’s the action items in such a case? Are we going to treat it as a backlog or how do we treat such items? It is not advisable or feasible to stretch the team beyond certain limit I mean sitting whole night and absorbing weekend to finish such story. Many a times i have treated such story as a backlog and removed from the current sprint. Your thought please..
Thank you for a great and concise article. As an executive, I found your explanation extremely helpful and well-thought out. I will help me, greatly, to be able to talk intelligently to my staff, while undertstanding more about their tasks and responsibilities.
Thank you, again!!!
Here are some major differences between both of these:
Scrum is known to be an agile framework that enables us to put all our efforts into delivering the business value in an appropriate manner and in as little time as possible. Scrum is typically or more concerned with the continuous process improvements. Scrum has quite a pre-defined structured framework.
Whereas, Kanban is a visual system that is used for managing all the software development work. This method nurtures continuous improvement, efficiency and it is highly likely that the productivity ratio increases using Kanban. Kanban is quite concerned with getting more work done and in a shorter time. Contrary, Kanban is less structured and it is based on a list of items to do.
Both Scrum and Kanban belongs to the same methodology i.e. Agile. Though both these terms have subtle differences between them, the principles are the same, meaning both will help to build better products and services.
Hi,
the article is really nice, but in the Kanban section, it says nothing about WIP limits. And I think this is the core of the Kanban board. Actually, I think that WIP limits create from a Kanban board a proper pull system where nobody is overloaded and the workflow is smooth and predictable(or as far as it is possible). So WIP limits are crucial if you want to apply Kanban properly.
Cheers
Hi,
I have 5 years of exp in Functional testing but I am interested in automation ,I have knowledge on selenium but no real time experience I am planning to switch but now I am getting a UFT project.
Suggest me if its fine to take the project as there is no much opportunity in UFT.
A simple yet efficient guide on the subject, thanks a lot for the details.
Thank you for the article 🙂 Was detailed and interesting 🙂 Although I am a kanbantool.com team 🙂 it doesn’t mean that I totally dislike scrum. It has its advantages as well. Kanban seems to be a lot easier though and little bit more intuitive 🙂 Just my opinion:)
Very nice article, I learned a lot
Tiny comment on a good summary: i wouldn’t say “No changes are allowed once the Sprint has started”. I would have to think long and hard about how exactly to word it, to keep it within your compact format, but, the key change allowed during a sprint is to drop items.
Thank you, very nice article.
For the last 2 years we are working in Agile, scrum; Kanban and applying more or less mix of all the methods & practices, however, nobody knew the difference between them. Now it’s pretty clear.
very nice article.lot of information for beginners.Thank you so much
In my initial understanding neither system satisfactorily replace the others comparative benefits. I would say however that Kazan is assuming that the scrum team already have the domain skills, where the idea of the scrum team is to enrich their domain skill usage, per iteration, per sprint, and it does depend on implementing a potentially marketable product. During this implementation stage (focus group tests etc) it covers most of the Creative Problem Solving Process CPSP (Goal setting/clarify stage, ideating stage, development stage, and implementation stage).
Kazan is an easy to understand board, and useful, and can be applied to individuals as can derivations of scrum, but Kazan doesn’t cover all the CPSP stages clearly enough, and that’s not so important, but it does mean those stages will be encultured by local variables, all of which will lead to hiccups unless someone is able to wash over them with domain skills.
I do like Kazan however, for it’s simplicity – less of a learning curve.
Thanks so much for putting the processes so clearly!
Very good points all are following
Thanks for the article , Very helpful explanation of differences between Kanban vs Scrum vs Agile.
Thanks so much. Very helpful explanation of differences between Kanban vs Scrum vs Agile.
Thank you for the interesting article. It’s great you write about differences between these two attitudes – however, it’s sometimes needed to concentrate on similarities, especially when you start working with specialists who already have some favourite attitudes chosen and these attitudes are (surprisingly ;)) not the same ones. One of my favourite ways to present these both sides of Kanban vs. Scrum competition is showing the https://kanbantool.com/kanban-library/scrum-and-kanban/kanban-vs-scrum-presentation presentation – short and informative one. So I would be really glad if you write another article about some similarities between our two heroes (maybe it is somewhere on your page already and I haven’t noticed it yet ;)). Thanks!
The Japanese word “kanban” does not mean “Visual Signal”. It means something like “signboard”.
Very good points
Very good point Kishore.
Stories are handpicked by the Sprint team in the planning stage, after discussions. Chances of getting technical difficulties during the Sprint are low. However, there are chances.
In case of a blocker Story, We normally re-analyze the story for the cause, drop the story if required and send it to the backlogs.
You were right when you said, “It is not advisable or feasible to stretch the team beyond certain limit I mean sitting whole night and absorbing weekend to finish such story.”
Great post. There is one thing I would like to point out. Agile is seen as a framework that sort of allows room to make many changes and can be seen as a very time flexible environment. Agile sort of sets standups, retro, planning etc which almost goes against the Agile way of working. Scrum is a methodology in Agile but it also sort of goes against Agile way of working. Its just a view I have had and been thinking about recently. Great post.
Shahin, when you wrote:”Agile sort of sets standups, retro, planning etc which almost goes against the Agile way of working.” I think that first “Agile” was meant to be “Scrum”. in which case I agree – I have had similar thoughts. Scrum seems quite process-heavy, lots of meetings and dogma. However, I suppose it does provide a more complete example of a process.
A very nice article. And to add up for the key of any process in software development is communication and attitude to say “I can do it.” or “Ill try to do it”. And be honest to say “you can’t do it.” because what we are doing in SW Development is trial an error no one knows about the impact but we are glad to have a process like Agile, Kanban and Scrum.
clear and nice explanation…
Amazing topic of scrum & agile differences that you have shared here. This will be more effective for career building. When I was looking for a job that time I found certified scrum master training from “tryScrum” for which I could make my career as level high. Really, this was so helpful for me.
nice Article, I would like share some point about it. which we follow while choose scrum vs kanban. Scrum is an agile process that allows us to focus on delivering the business value in the shortest time.
Kanban is a visual system for managing software development work.
Kanban method fosters continuous improvement, productivity and efficiency are likely to increase.
Scrum is focused on the backlog while kanban on dashboard.
Scrum master acts as a problem solver.
Kanban encourages every team member a leader and sharing responsibility amongst them all.
Scrum prescribes time-boxed iterations.
Kanban focuses on planning a different duration for individual iteration.
Nice article to help with the discernment for these different practices. One question from someone who is familiar with SCRUM but not with Kanban, the summary comparison between the methodologies contrasts SCRUM operating on the basis of roles and Kanban not. Within the detail of Kanban, a product owner is listed as responsible for prioritizing the to do list. So are things like a team (also identified in the Kanban description) and a product owner generic Agile concepts that Kanban utilizes (but does not define) or is this in need of correction? Looking to understand.
Explaining Kanban, you wrote the following:
“Only when the work item is moved to DONE state, they pick the next work item from the Backlog/to do list.”
This is not really correct. In Kanban, each column on the board can carry a limited number of cards. The limits may differ in each column. For instance 4 cards in “In Development” and 2 cards in “In Test”. As long as the limits are not reached, cards can be pulled into the column.
Thanks for the effort of writing.