Many companies from across industries use agility to tackle huge projects. Scrum and Kanban are two powerful approaches to agility used to make project management efficient. However, each of these approaches comes with its own norms of functioning. Let’s now look at how they compare against each other.

An overview of Kanban

Kanban is a methodology which helps you manage workflows, largely with the aid of a simple visual interface called the Kanban board. In Kanban, the tasks currently in progress are limited at any stage in a project. This is to ensure that at any given point, the team’s capacity is optimally utilized.

To make sure that you get the most work done with the existing team, without sacrificing quality, Kanban consists of two sets of principles and six core practices.

The two sets of principles are Change Management Principles and Service Delivery Principles.

The change management principles include the following: 1)Start with the tasks that you are performing at the moment 2)Follow incremental changes as the project progresses rather than bringing about massive progress in one go 3)Leaderships acts shouldn’t be limited to those in any particular tier of the hierarchy. Such acts should be encouraged all across all levels.

Now, let’s look at the service delivery principles: 1)Stay focused on the expectations and requirements of the customers. 2)You should focus on managing the work and not those who are performing the work. 3)You should periodically review the network of services.

There are six different practices in Kanban. These are: 1)Visualizing the workflow 2) Limiting the number of tasks that are currently in progress 3) Managing the flow of work 4)Ensuring that process policies are made explicit 5)Establishing feedback loops and 6)Improving the process with collaborative efforts.

An overview of Scrum

Scrum, on the other hand, is a more rigid framework to manage workflow when it’s compared to Kanban. The planning involved in scrum is far more detailed than in Kanban.

Scrum comes with a set of clearly defines processes and roles, and the framework is based upon three pillars. These are Transparency, Inspection and Adaptation.

The core idea of the scrum framework is to cut down a project into a series of smaller tasks, each of which needs to be finished within a particular frame of time. An iteration in which one of these tasks is done is called a sprint. A sprint is a pre-determined unit so that no additional tasks are included in one after it is started.

Now that you know what Kanban and scrum entail on a basic level, we shall now look at how these two project management frameworks differ from and are similar to each other.

Roles

In Scrum, there are certain roles that are to be mandatorily assigned to team members. These include the role of a Scrum Master, Product Owner and also the Development team.

Out of these, the scrum master decides the timelines in which sprints are to be finished. The product owner, meanwhile, is primarily responsible for directing the team during the project’s progress. They should also see to it that the tasks in the backlog are added to the relevant sprints. The development team executes the tasks that have been determined during the sprint planning.

Contrasting with Scrum, in Kanban, you can maintain the current organizational structure to a good extent. There are two roles which you could introduce: Service delivery manager, and Service request manager. But do note that there aren’t mandatory roles.

The role of the service delivery manager entails making sure that the tasks in a project are performed in the order they are meant to be, and get finished at the appropriate times. If the team members are found to face some issue that keeps them from finishing a task, the service delivery manager should help them out with the same. Another duty of a service delivery manager is to devise and implement activities that support continuous improvement in a team.

The role of the service request manager, meanwhile, entails ensuring that the process policies are thoroughly followed by the team members. They should also strive to improve the quality of the corporate governance within a team. Another duty of the role is to help bring down the risks that are linked to individual members of the team. But the service request manager is rarely considered a separate role. It’s usually a set of duties that the team’s manager takes in addition to their regular duties.

Planning

In Scrum, the planning occurs iteratively, before the start of every sprint. A meeting is conducted solely for planning. The participants of these meetings include the product owner, the product development team and the scrum master.

In these meetings, the participants would transform the user stories- which could be considered use cases- into actionable tasks. After that, the time required to perform all the tasks is estimated. If there is an agreement regarding the tasks and the time estimate, the team is them committed to completing all the tasks in the coming sprint. On the odd occasions when requirements change in the course of a sprint, the sprint itself could be abandoned and another planning session is conducted before the next sprint.

While planning in Scrum is based on the sprint that is to come, Kanban relies on a retro-active method by which the planning is done based on data from previous workflows. This data would include the types of tasks and services as well as other related factors from previous workflows.

Unlike in Scrum, the work is not iterative but linear in Kanban. It is common enough to add upcoming tasks in a column for the coming week or month in the Kanban board. Whenever the development team has finished their current tasks and has time to work on new tasks, you could add new tasks in the “In Progress” section of the board. After a certain number of tasks are finished, you would get an idea of how long tasks of different types takes to be finished. Based on this, you can forecast the time it would take for the rest of the tasks to be completed. You could then assign the finish date for each task accordingly.

Commitment

In Kanban, long-term commitment is deferred for as long as is practical. This is to support agility, thereby ensuring that value is delivered at a frequent rate to the end customer. Typically, the commitment of a team member is limited to the task that they are currently performing. Only after they have finished the task would they start on a new task.

 The approach to commitment is different in Scrum though. In this methodology, the commitment is based on what’s assumed as precise forecasting- the purported end result of a sprint and also the tasks that are required to generate that result. If an unexpected issue arises during a sprint, there is a chance that the sprint itself may need to be abandoned. The sprint could also fail if the team’s capacity has been misjudged in relation to the number of tasks that need to be performed in it.

Performance indicators

It’s impossible to get an objective analysis of a project’s progress unless you set specific key performance indicators or KPIs at the outset of the project itself. However, both Scrum and Kanban have different sets of KPIs.

Let’s look at the KPIs in Scrum first.

In Scrum, you should be conscious of two major KPIs: Velocity and Planned Capacity.

Out of these, velocity is predicated on the number of story points that are finished in a project. This is essentially an average number of tasks in all the sprints that have been done so far. Based on this number, you could plan the number of backlog items you could add in the coming sprint.

Planned capacity, as you may have guessed, is how much bandwidth a team has to perform a sprint. The capacity would depend on many factors including if any team members are away on a vacation or on leave because of illness. While planning a sprint, it is extremely important to correctly assess the capacity. If the team’s capacity is not much, you should take up only fewer action items from the backlog. On the other hand, if more members have been added to the team, you could consider pulling more tasks from the backlog and including them in the sprint.

Backlogs have a tendency to get piled up when you are not looking. To ensure that that doesn’t happen, teams following the Scrum methodology usually use certain charts, called the Burndown chart and Velocity Chart.

The Burndown Chart visually depicts the number of tasks that are yet to be finished against the time remaining in the sprint. Velocity charts, meanwhile, typically are histograms that depict the team’s performance so far.

Now, let’s look at the KPIs in Kanban.

Lead time and Cycle time are the two most important metrics that are used in the Kanban methodology.

Lead time is the time between when a task pops up in the workflow and when it is finished and leaves the flow. Lead time starts counting once you commit to performing a task.

Cycle time meanwhile is the time that one actually works on a task. It starts counting from when a particular task is in the “in progress” stage. Typically, both these KPIs are measured in days. The goal of the team is to keep these values as low as possible.

As was the case with Scrum, Kanban to incorporates two types of charts to task the progress of tasks easily. These are

the cumulative flow diagram or CFD and Cycle time histogram.  The purpose of the CFD is to provide a visual representation of the workflow so that you could learn where to give your attention to make the process more streamlined and predictable. Meanwhile, the cycle time histogram is meant to help you gauge how the process is performing from time to time.

 Meetings

As mentioned before, in Kanban, meetings are not mandatory. However, if you still plan to have them, there are two types of meetings you could choose from. These are service-oriented cadences and team-level cadences. Both these types of meetings help you keep your team properly oriented towards the workflow and also ensure that the workflow is progressing steadily.

Under these main categories of meetings, you could in turn have different types of meetings. These include operations review, daily meeting, delivery planning meeting, strategy review, replenishment and commitment meeting, service delivery review and risk review.

You could even combine some of these meetings or skip them according to your requirements. The most important thing is to ensure that a meeting or combination of meetings is useful for the team. If it’s not, you can always forsake it and try another form of meeting from the list, or combinations thereof.

Coming to scrum, every sprint cycle included four types of meetings. There are daily scrum, sprint planning, sprint review and sprint retrospective. Unlike in Kanban, scrum meetings are mandatory. Aside from the four types just mentioned, there is also backlog refinement. It is not a meeting type included in the scrum guide. Nevertheless, it is one which many scrum teams use, typically as a sprint is close to its end. It is used to reprioritize the user stories if required.

Sprint planning meanwhile is held at the start of a sprint and is used for delegating the tasks to everyone. Once you have the team members’ commitment to performing the tasks, the team should meet every single day to discuss the progress of their tasks and also any problems they may be facing.  This is the daily scrum. After a sprint is finished, the team members and other stakeholders may meet to do a review of what they have achieved during the sprint. This happens in the sprint review. In the sprint retrospective, the team members evaluate what are the elements which have worked well in the previous sprint, and also what could have gone better. This latter could give them ideas on how to improve in the coming sprint.

Boards

Both scrum and Kanban use boards that depict workflow visually to help you manage the workflow. But the boards used in both are different in significant ways.

In scrum, the board is essentially a counterpart to the tasks in the backlog. Once a team is committed to taking up a set volume of tasks, those tasks are added to the backlog on the scrum board. The team members would then start the tasks which then become part of ‘work in progress.’ The objective is to finish all the proposed tasks before the sprint is finished. After every sprint, the board is reset to be a clean slate.

The Kanban board functions differently from this. In Kanban, the board is an uninterrupted map that depicts the process. While building the board, the aum should be to create a Kanban system that is robust enough to support a smooth workflow over a long period of time. Ideally, the Kanban board would also have the Work in progress(WIP) limits depicted in it. The objective with this is to be able to keep a check on the volume of tasks that enter and leave a process so that a good speed of delivery can be maintained.

The software solutions

We saw before that the Kanban method functions with the Kanban board as a basis. The same is true about the Kanban software as well. Put another way, all the tasks that a team should perform and their state of progress would be visible on the software. This way, everyone in the team could easily access crucial information about the workflow through the software.

Every unit of work or task is depicted in the software as a card. There would be columns that represent the different stages of work in the process. Also, there would be swim lanes which indicate the priority for each lane.

Scrum software traditionally has relied on mostly text-oriented interfaces rather than visual depictions like a Kanban board. The depiction of workflow in it is similar to computer folders with different items inside them. However, of late, there has been a shift in how the interface-id is designed in many scrum tools, towards a more visual-oriented style of representing workflow in boards. Keeping with the modus operandi of the scrum methodology, you should add the tasks to these boards before a sprint begins and should ensure that they remain on the board until the sprint is finished.

Once all the tasks are finished, you could consider the sprint as done. If a new task comes in, the requirement could be reviewed and a new sprint could be begun.

Every sprint is followed by a retrospective meeting. During this meeting, the board needs to be reset, thereby readying it for the next sprint. Usually, the scrum board is not owned by a homogenous team. The ownership rests with a cross-functional team with members from different functional areas who have come together to successfully complete a sprint.

The WIP limit should be set before the start of every sprint. The team members commit to finishing a precise number of tasks without which the sprint couldn’t be completed. For this reason, it is extremely important not to have the WIP limit surpass the time availability of the team.  In other words, the number of tasks in a sprint(which is the WIP limit in this case) should match or be lesser than the total time availability of the team.

Unlike a scrum board, a Kanban board isn’t owned by any cross-functional team. Also, the work-in-progress limits are set not only before the workflow starts but also during the workflow stages, depending on the changing requirements that happen during a workflow. This helps the team reorganize themselves to tackle any unexpected bottlenecks that may happen during the workflow.

A Kanban software platform would ideally have the columns in the board labelled so that it shows not just the different stages in the workflow but also the work-in-progress limit which is set for each column. The WIP limit denotes the highest number of tasks that could enter a particular work stage.

Whereas in scrum tools, each sprint is defined to be of a certain duration, no time limits are set on Kanban boards. You could add new tasks or cards to the board at a point during the workflow, provided the number of total tasks doesn’t surpass the WIP limits. This also means that there is no need for the board to be reset on a periodic basis.

Certain Kanban software tools also let you gather data related to every task which appears on the Kanban board. You could use the data to identify bottlenecks and also improve the average time in which tasks are finished.

Tracking progress

Efficiently tracking the progress of tasks and project is of importance for a project manager, in both scrum and Kanban projects.

Scrum software platforms usually have a backlog where you could place all future tasks for a particular sprint. To ensure that the pace of tasks progress doesn’t slack, these tools come with a burndown chart.

The burndown chart shows you the volume of work that is still left to be done to finish the project. Burndown charts are handy if you need to give a quick glance at where the project has reached the moment. However, if there are progress gaps these are hard to identify with the burndown charts. The chart summarizes the amount of work that all the members of the team have done so far. If process gaps occur and work gets affected, the burn charts only show that as a drop in the amount of completed work.

You will need to figure out the reason for the drop yourself, as the software wouldn’t assist you with the same.

As mentioned earlier, there is no predetermined duration in which tasks are to be finished in Kanban. For this reason, Kanban software tools don’t require burndown charts at all. Rather, these tools typically come with what is called a cumulative flow diagram.

This diagram will collect data related to all the tasks that get into a workflow automatically.

You could use this data to find out the average time it takes to finish an assignment. This way, the cumulative flow diagram could have the tasks in a workflow and also the time duration that each task remained in a particular work stage. This makes it easy to identify if any work stages are blocking cards, thereby creating a bottleneck. The more duration a card remains in a stage, the broader the stage will appear in the

diagram. This makes it easy to locate the areas in the workflows where bottlenecks are arising. You could then take the necessary action to solve the problem.

Estimating the work

Estimating how much work is involved in a project or a sprint is of critical importance in scrum projects and by extension, in scrum software platforms. Typically, this estimation is done by the whole team while refining the backlog. Not only should they make sure that the tasks are properly quantified, but they should also be matched according to the bandwidth of the team for the coming sprint.

Sizing up a task is typically performed using the Fibonacci sequence. After all the tasks in a project are thus weighed, you could decide how many of them could be performed in the coming sprint. In scrum software platforms, you could assign story points for each of the user stories- this indicates how resource-intensive a particular task is. You could also keep track of how the tracks are progressing in the software.

Teams usually need to spend substantial amounts of time estimating the workload. In fact, more often than not, the value of this estimation process is dubious. The truth is that you could rarely predict the volume of work involved in a sprint accurately. The original estimation going wrong is more the rule than the exception.

In Kanban, one usually cuts down large tasks into smaller tasks. The objective is to keep individual tasks at the smallest possible size without affecting the value of the deliverable. This approach has two advantages- it helps execute tasks easier, and it helps keep the workflow steady and predictable.

Rather than predicting the workload based on tasks, in Kanban, previous process cycle times are taken as the foundation to estimate how much work could be performed in a given period of time. Certain Kanban software tools make automatic calculations based on previous data to give you an estimate of the number of tasks a team could finish within a time period. Compared to scrum methodology, Kanban projects usually yield better estimates of workload. This is in turn reflected in Kanban software tools as well.

Is there a clear winner in Scrum vs Kanban?

Both scrum and Kanban are methodologies that agile teams could adopt to manage their projects. But which of this one should adopt would depend more on the nature of the projects than anything. Scrum usually fares poorly in projects that are too long. Kanban meanwhile is a poor choice if you expect the demands from the project to keep fluctuating, as the methodology is not designed to deal with such variabilities.

The bottom line is that there is no objective measure to decide which methodology is better than the one. The usability of either depends on the type of project. But now that you have seen the differences between the two in detail, you should be able to easily decide which is better suited for your purposes.

Regardless of the approach that you pick, it’s a good idea to use a good project management tool that supports agile projects. I’m Productive is an example of a project management tool which is ideal for agile projects. For managing sprints or managing projects using Kanban boards, the platform has in-built features that make project management as easy as it is efficient. The tool even comes equipped with artificial intelligence which helps you predict the project delivery accurately. You could get this estimate with just a click of a button. 

Please head to the website, to learn more.