Scrum and Kanban — an Agile comparison
Project Management is an easy field of topic to work than to study in order to take the exam.
This is my personal opinion. Three years of project management education at any University can be made equivalent to 18 months of work experience as a project manager. After all, project management is all about doing things right. The more you do, the more you learn. PMI, gives a whole range of fields [UC1] to master in order to take the PMI exam. But I think to manage a project, all you need to master is Risk Management, Time and Cost management and Resource and communication management. The reason being, the responsibility of the PM can be listed as the five following roles: Administrator, Mentor, Provider, Recruiter and Keeper.
Having worked in both Waterfall and Agile framework [UC2] of Project Management, I know Agile methodologies differ from the Waterfall Project management in two main aspects 1) Change acceptance 2) Feedback based control. There are many agile methodologies and each of them differ in the way of implementation of the concept of empiricism, mentioned in Agile manifesto and advocated by many Agile Pundits. Irrespective of methodologies, all agile framework insists on teamwork, accountability, communication and value deliverance.
As far as my knowledge reaches, there are five forms of agile methodologies: Scrum, Kanban, Lean Six Sigma, Extreme Programming (XP), Scaled Agile [UC3]
As Kanban[UC4] is gaining more and more importance in many parts of world, similar to any methodological concept developed in Japan, I thought I can also focus on the same and pin point the basic differences between Scrum and Kanban and why Kanban [UC5] is thought to be better to Scrum when it comes to controlling the workflow. After many conversations in both semi-formal and causal set up with Agile gurus, I have found three main differences between Scrum and Kanban: Apparent Task Identification, Completion Definition, Work Board
1) Apparent Task Identification : Scrum identifies a task as a part of a sprint (iteration) or a MVP, whereas Kanban looks at a task as an individual task linked to the product and not to a sprint. In other words, Scrum uses a top down hierarchical approach, where a product is split into number of user stories or tasks belonging to many sprints and they are completed to complete a sprint.
2) Completion Definition: Scrum completion is defined in terms of sprints, so it allows any amount of user stories to be open in order to complete a sprint, whereas Kanban limits the amount of tasks performed at any time. The focus is more on completing the tasks in order to build the product instead of performing all the tasks pertaining to a specific feature defined as MVP at the same time. This is the real secret of Kanban’s success with work flow. Kanban follows a hierarchical bottom up approach, where the individual tasks are completed one by one and put together as a product.
3) Work Board: The Scrum work board for every sprint moves from left to right , establishing a rigid pull system, whereas Kanban workflow reveals a flexible pull system [UC6] as the work flows from left to right ( from analyze to test) , there is continuous flow of work into the board from the product backlog leaving the work board never empty. This is the concept behind a success of Kanban workflow. In other words, there is always work to do.
Now for a detailed look at the various differences:
Concept: As I mentioned above, Scrum is a rigid pull agile methodology, where the team members are allocated what to do, how many user stories they can handle, during the standup scrum meeting attended by scrum master, product owner and team, at the beginning of a sprint. Nonetheless, Kanban is a flexible pull system, where the team members have designated tasks [UC7] during planning, however they pull as much tasks as possible from the product backlog, as the iteration life cycle pass by.
Team comparison: Scrum consists of a cross-functional team of developers, PO and Scrum Master, while Kanban’s team has each person designated for their job. Kanban‘s team is not rigid as well and though PO and Scrum Master is being called as ‘Service Request Manager’ and ‘Service Delivery Manager’, respectively, any stakeholder can become the product owner and his input is taken. In Scrum, the powers of the product owner are limited. He cannot make changes to the scrum work board without consulting the Team, as the team owns the work board. On the other hand, Kanban allows the work board to be modified by the Service request manager or any other stakeholder, as the board is not owned by the team.
Work flow Comparison : Scrum has four workflow stages while Kanban has five stages of workflow. While the work flow time (the time taken to complete a sprint) in scrum is called the ‘sprint time box’, Kanban refers it as ‘average WIP (Work in Progress — number of items in progress) duration’. While the sprint time box is fixed as 1- 4 weeks, whereas Kanban allows more flexibility in time while it comes to deciding WIP limits. When it comes to sprint time box, sprint is more rigid and similar to waterfall methods of project management, while Kanban is more agile and flexible.
Board Comparison: Scrum board has plan, (Total no. of user stories), do (the stories to be completed in the current iteration), check ( to check the product with the PO and other stakeholders ) and deliver (completed MVP is delivered after retrospective) in their work flow, while Kanban has analyze (a decision is made on the number of tasks to be pulled from the product backlog), review ( the decision is reviewed and temporary[UC8] limitation is set on the amount of tasks pulled by the team at any time, based on the cadence of the team), build ( the tasks in progress) and integrate ( Manage and enhance the flow by integrating the finished tasks [UC9] with the product and also to improve the lag [UC10] between lead time [UC11] and cycle time[UC12] ) and test ( Check the completed tasks with the service request manager and other owners) correspondingly. The one other major difference between the two boards is Scrum does not limit the no of user stories in the ‘do’ column, while Kanban team limits the same to 2 or 4, depending on the required cadence. Also the scrum board resets after every sprint, whereas the Kanban board is continuous.
Plan Sessions: Sprint plan is fixed, while Kanban plan is flexible. In Kanban, the number of user stories agreed by the team during the plan sessions, can be changed as the number of work items need to be added or need to be deleted as and when the need arises. This is similar to scrum, where the user stories are added, prioritized and ordered based on the requirement of the team, product owner and the scrum master. The PO or the customer is responsible in both Scrum and Kanban for understanding the backlog item well and define them based on the size and the time criticality of the same. He is responsible to set the tasks priorities as well.
The build team: The knowledge and the know-how of the developing team in Scrum can be visualized like the alphabet ‘ T ‘, where the members are well versed with all the areas of the sprint in broad perspective[UC13] , but have in depth knowledge [UC14] in only one, however the team in Kanban is known for its specialization and can referred as a ‘S’[UC15] .
Artifacts: Scrum has five artifacts, (Product backlog, Sprint backlog, Burn up chart (shows the time span and the total work completed) , Burn down chart (which tells the amount of work completed in each sprint ) and velocity chart, (which specifies the no of story points completed per sprint) . Kanban does not have specific charts. It is flexible and allows the team to do the required charts when necessary, however they do have Team backlog, which is basically all the work items belonging to a feature which provides value, cumulative flow diagram, which gives the arrival curve ( Work items just pulled from team backlog ) and departure curve ( Completed work items) , and this gives a good indication of lead time (x- axis ) and WIP (y axis), between the two curves. This is the metric used in Kanban, to arrive at the iteration cadence. To arrive at the current iteration, the team calculates the no of tasks completed per day, by dividing WIP by Lead time.
Rules and Procedures: Extreme Prescriptive is when everything happens as per the rules and extreme adaptive is chaos. So Scrum has many rules compared to Kanban, while Kanban technique is more flexible compared to Scrum. But Kanban do have rules.
Framework: Scrum framework is based on transparency (common language) , inspection ( prevention of undesired variances) and adaptation( response based control) , whereas the Kanban framework is based on transparent bucket system or container system where the work flow can be contained to 2–4 tasks, incremental improvements to the existing system and ‘need based build and release ‘ is emphasized.
It’s widely accepted about Kanban being a better agile method than Scrum, due to its faster delivery times, but one major drawback. (No one knows when the product will be released exactly). But I think, there are few more advantages Kanban brings to your project and your team
1) Pull as you finish method of Kanban, keeps the team motivated and protect them from overstress.
2) The idea of the work flow improvement through understanding the current processes and respecting the existing roles and titles, bring more flexibility into your organization leading to more overall adaptation of Kanban and not merely for IT or software projects.
3) Qualitative and quantitative understanding of the work flow helps in sustainable development of the business and hence Kanban leans more towards lean development.
4) The exponential improvement of the cycle time leads to increased predictability, shorter delivery times and improved customer satisfaction.
To summarize, when it comes to the flag-end of the race, there’s no definite winner. Scrum and Kanban have a few similarities and many differences which makes them both adaptable and desirable.
Both methodologies are empirical, both allow splitting the product into manageable tasks, both are Lean agile pull systems, both use transparency in their process, both limit the number of tasks done at any one instant.
The differences are Scrum is good for estimation, schedule allocation, team capability, evaluation of team performance in both project and product management, while Kanban is highly useful to improve work flow, increase cycle times (start of work to end of work item — elapsed time) better throughput (the units of work finished during a length of time) through accommodating changes within, whenever required.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
UC comments explained:
[UC1]Procurement management, Risk Management, Integration management, Quality Management, Time and Cost management, Scope management, HR and communication management.
[UC2]For more info on Agile Scrum, check out my linkedin article on ‘Agile in 1000 words’, published on June 24, 2019,
Agile in 1000 words
This article is written for those project managers who have been working in waterfall for too long and are struggling…
[UC3]There are many variations of scaled agile such as DSDM, ASD, FDD, DA, Nexus etc.,
[UC4]Kanban in Japanese means ‘Billboard’ or ‘Visual Representation’. The reason for this name being used for a framework which improves work flow is because most times work is visible while flow is invisible, making it difficult to realize whether the work is finished or not. Thus Kanban lays down the rules to see the work flow in real time.
[UC5]My experience with Kanban style of agile is less and hence I have sought help from many agile gurus with more Kanban experience and Scrum pundits who values Kanban and choose to adopt it as their favorite agile method.
[UC6]Rather a push and pull system where a task is pulled from the product backlog as and when another task in the board moves to ‘done’ column in the work board.
[UC7]Many Kanban teams call the tasks as tickets to be taken.
[UC8]The word ‘temporary’ is used to emphasize the concept of flexibility when it comes to accepting the amount of tasks by the team.
[UC9]Currently completed with the previously completed tasks.
[UC10]The lag between the lead and the cycle time is because customer starts his work clock, as soon as the tasks are requested and analyzed, but the team’s clock starts only after the review is made.
[UC11]Lead time in Kanban is defined as the average time taken to finish a ticket from the point of view of the customer.
[UC12]Cycle time is defined as the average time taken from start to finish of a task from the point of view of the team.
[UC13]This refers to the horizontal line in ‘T’
[UC14]This refers to the vertical deep line in the alphabet ‘T’.
[UC15]The alphabet ‘S’ is written in a single stroke and the pressure is same all over the written alphabet emphasizing the overall specialized knowledge needed to complete a tasks requirement.