One of the key elements of project management is deciding for the right project management method. Almost every page related to software development includes buzzwords as "we are agile", "we work according to the Kanban methodology" or "we are Scrum ninjas". While it is not a problem to identify the differences between traditional and agile methods of managing projects, understanding the discrepancies between the Scrum and Kanban methodologies can be a problem for many.
We decided to take both methods - Scrum and Kanban - under the magnifying glass and find out their characteristics, similarities, and differences.
Agil, Scrum, Kanban… isn't it basically all the same?
If you’re new to the project management methodologies, you might be under the impression that “Scrum” and “Agile” are pretty much the same. But that’s not really the case.
Agile is an approach to project management that refers to a set of guidelines and practices based on the Agile Manifesto. Basically, the term "agility" describes its purpose very well: to remain agile and flexible, to react to changes and to remain adaptable, to work independently...
Scrum as well as Kanban, on the other hand, are simply two project management methodologies which are considered to be agile. If you are only judging the book by its cover also the two methodologies might seem to be one like the other. After all, both within Scrum and Kanban it is all about getting the open task to the status “Done”. Also, both practices use a ‘Board’ to do so – which is pretty much the most striking instrument. Yet, there are some major differences between them that every project manager should be aware of.
Scrum
The main concern is to explore new ways while decreasing the risks.
Scrum is a framework for team collaboration that helps the whole team working on complex products and stay creative all the way through. Having a look into the Scrum Guide helps understanding the concept a little better:
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
That means, that the measures the team is going to undertake in future are based on the experiences made during the ongoing process for the greater part. Within this approach Scrum implies so called Sprints (iterative) – regular iterations, each of them ending with an “finished” interim result/product (incremental). This “step-by-step”-approach also minimizes the risk of experimental activities (every sprint-result is open to feedback from all stakeholders). Therefore, it opens opportunities for exploring some new ideas.
Scrum Artefacts
Scrum aims to remain flexible and transparent in order to facilitate a better feedback culture and changes within the process. The common goal is to provide value to the clients and to create a fully-functional piece of software in the end. In order to do so, scrum works with so called Events (regular meetings) and three Artifacts:
1. Product Backlog
The Product Backlog is a list of all items/requirements for the final product, created, managed and prioritized by the Product Owner. It is his own “little” space, so to say, where he collects everything (features, improvements, fixes etc.) that needs to be done with the product. Its structure is quite simple: Most important items can be found at the top of the list.
You can tell, the Procut Backlog is neither a fixed list nor is it fully elaborated at the very beginning. Actually, it is never fully complete but evolves together with the product itself.
In reality teams often work with User Stories, that describe features from the users’ point of view and therefore also the specific requirements.
Though, it is quite important that these stories are easy to understand.
As a [user role] I want to [function] in order to [benefit].
2. Sprint Backlog
The hole Product Backlog strategy is quite simple, right? However, there are a lot of items on the list already. How many of these items need to be completed during the next sprint anyways? Well, that’s what the Sprint Backlog is for. The Sprint Backlog happens to be some kind of smaller version of a Product Backlog, containing selected items that need to be worked off during the next Sprint.
The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
3. Product Increment
As revealed already, the Product Increment can be seen as the result of each sprint, which means that it also is the sum of all the Product Backlog items completed during a Sprint. It needs to be “Done” (according to definition of the team) by the end of it.
How all these Artifacts work together and how the whole Scrum process is organized can be best seen by having a look at a Scrum Board:
The Scrum Team
Scrum defines three basic roles:
1. The Product Owner
There is the Product Owner (PO), who is the one being in charge of getting the best out of the product the team possibly can.
What the PO also owns is the Product Backlog! The PO creates, structures, expands, changes and generally manages all items in the Product Backlog all the way through the projects process. He prioritizes all the tasks and no one besides him can change anything about that. The one person that fills this role is accountable for the success and failure of the project.
2. The Development Team ("The Team")
The Goal of the Development is to process the Sprint Backlog to finally receive a ‘done’ increment that can be presented by the end. As all parties involved the team is free to make its own decisions – especially about the task assignment.
A Scrum Development Team needs to be capable but still easy to coordinate which is why the size of the Team matters a lot. To guarantee this, it’s recommended to count 3-9 members.
3. The Scrum Master
The last role within the Scrum Team is the Scrum Master, who helps the whole team to understand and to follow the Scrum principles at all times.
“I keep an eye on the process!”
What’s interesting is that nobody really manages the whole Scrum team, which is self-organizing and stays dynamic.
Scrum Events and Process
Now that we’ve discovered the main components, let’s head over to the procedure itself and put them in context. The centerpiece of scrum are (as mentioned already) the sprints. A sprint is one of 5 Scrum Events and basically consists of the other events:
| Sprint |
| Sprint Planning | Daily Scrums | Sprint Review | Sprint Retrospective |
A Sprint should be no longer than one month. The actual length depends on individual factors – such as the ability of the development team, the complexity of the tasks etc. – though, shorter intervals of (two weeks) may be preferred as they enable the team to uncover problems faster.
The Sprint Planning is there to clarify what the team is able to accomplish. This event marks the start of the Sprint. Based on priorities set by the Product Owner and the time estimations for specific tasks, the team selects a certain number of items from the Backlog and defines a Sprint Goal. It is extremely important that the team understands what is feasible and what is not as there shouldn’t be any changes until the Sprint ends.
Having clarified what needs to be done and how it will be done, the team jumps right into the process itself and focuses on completing the previously selected items. This is much easier thanks to a Scrum Board, which helps to organize the Backlog, everyone’s tasks, and resources. It also happens to maintain transparency of tasks progression and team responsibilities. The process also includes Daily Scrums – regular 15-minutes long meetings to plan the work for the following 24 hours and to define possible barriers and problems.
All task are "Done"? The Product Increment can finally be showed to the stakeholders during a Sprint Review. This event is also an option to update the Product Backlog and think of anything that is to be done next.
Finally, the Sprint Retrospective marks the end of the sprint. The event is usually held by the Scrum Master, who gives feedback on both positive and negative aspects of the process. Also, possible ways of streamlining the process are to be discussed during the Sprint Retrospective.
Together with some improvement suggestions the next Sprint is just about to start...
Scrum in short
8 super easy steps for you to get started in no time:
- Get you a print of the official Scrum-Guide to guide you the path:
- Assign the roles: Pick a Product Owner, Scrum Master and Development Team. Note: Scrum works for small, cross-functional, self-organized teams (with up to 9 members).
- Create your Scrum Board. A simple Whiteboard or virtually on Stackfield. Both is possible. Both will add more transparency to your workflows.
- Create a Product Backlog. There you can list all product items/requirements and prioritize them. Note: The Product Backlog is to be maintained continuously.
- Plan your first Sprint. All items relevant to the first increment will move from Product Backlog to Sprint Backlog. Note: Sprints shouldn’t be longer than 4 Weeks.
- Integrate Daily Scrums. Daily meetings within a sprint provide the most important updates within no more than 15 min to all team members. Note: We recommend to choose a fixed time and place for your meetings to keep your routine and make the process easier.
- Have a Sprint Review. Discuss your finished increment as well as all updates for the backlog.
- Have a Sprint Retrospective. Discuss the good and bad experiences you had during the sprint and how your team is going to optimize your process.
Kanban
The main concern is to get more work done faster.
Contrary to Scrum, Kanban has only a few important rules:
- to visualize the workflow
- to limit work in progress
- to measure and improve flow
Work it off step by step
The project management method has very little structure - the team's sole goal is to shorten the time it takes to complete a project. Kanban is all about visualizing work processes and limiting work in progress. By completing one task after the other, step by step, inefficiency that arises due to multitasking will be prevented.
Visualizing workflows with the Kanban board
The methods heart is the so-called Kanban board, which maps the entire workflow in a well-structured way. For each task, individual cards (kan) can be created that visualize (ban) the status of the project within a set of process steps (e.g., Backlog, To Do, WIP, Testing, Done). You can tell, the basic structure of Scrum and Kanban Boards is quite similar. Let's take a closer look at the Kanban board to reveal the differences:
Workflows within the Kanban method can be best described as a continuous flow. Participants pick one card at a time, work them out, and – as the project moves on – one request after the other moves into the "Done" column until the project is completed. Apparently, the workflow is continuous – unlike Scrum workflows, where there is a cut after each sprint, "a reset" so to say right before a new sprint with a new starting product begins. But how does a Kanban team keep track of anything? The work-in-progress tasks are limited to a certain number of tasks. Hence, tasks must be completed before new ones can begin, simple as that.
Free way of project management
Unlike Scrum, Kanban does not dictate special roles or meetings. Also, there are no rules regarding iterations. Changes and new requirements can therefore be included in the processing at any time and directly, since there are no rigid requirements that must be met.
Kanban in short
- Create a Backlog. List all items and requirements that are to be assigned during the project process.
- Create a Kanban Board. Try to create a perfect workflow for you processes and to visualize it on a Kanban word in the best possible way. The steps / status columns are up to you but there should be at least a single column for “To Do”, “WIP” and “Done”.
- Specify a WIP limit.
- Control your progress and improve it if necessary.
Scrum vs Kanban: which product management method to choose?
First of all, these two product management methods have the same goal: bringing the final product in the most effective way possible while continually improving the development process. Both Scrum and Kanban are based on incremental development, in other words, on breaking down large tasks into smaller batches – the first with Sprints the latter with a WIP limit.
Certainly, on a large level of generality, the project management methodology that has more rules and regulations is Scrum. Though, this doesn’t mean that Kanban is the better method in general.
Scrum provides some limitations (artefacts, roles, events). Kanban on the other side requires nothing more than an option to visualize workflows – whether digital or analog (e.g. with a whiteboard). Yet, Scrum creates clear structures by asking for special roles: the Product Owner (who defines the product vision and priorities), the Team (who implements the product elements) and the Scrum Master (who tries to remove all obstacles to implementation, ensures effective workflow of the process). On the contrary, Kanban does not impose any of these roles.
Interestingly, 46% of organizations surveyed by the Project Management Institute use or have used an Agile or hybrid Agile approach in 2018. In reality, hybrid methods are not uncommon - many teams are using hybrid models influenced Scrum and Kanban, especially since advanced project management software can easily be adapted to the chosen methodology. It’s always a good practice to get familiar with “the standard options” first, to choose the approach that will work for you best.
While choosing the best method, it is worth taking a few factors into consideration:
Type of project
Is the project complex and requires detailed planning? Are the processes predictable (over sprints of at least two weeks)? Is the product still in development including some unknowns so that cost and risk cannot yet be estimated? Is it necessary to develop a product in its best possible form? In these cases, Scrum is a good choice. Scrum is a great way to integrate ideas and new approaches without taking too much risk: bottlenecks or insurmountable problem can easily be discovered by the end of the Sprint. In this case it costs the project only this one iteration or increment. At the center of Scrum is exploration, experimentation and risk minimization. Teams look for the best possible solution and the way to get there is usually on the path itself.
If, on the other hand, the main goal of the team is to use agile methods to create transparency and make processes fluent and effective, Kanban should be considered. Small projects with low complexity are well served with Kanban, as well as projects where the end result is not a product. Kanban also works well to structure workflows in general. Administrative tasks, customer queries or simply the tasks to be done in law firms, for example - this kind of work is difficult to plan and to jam into sprints. Also, there is no product target that requires development or even increments. In such cases, the sole aim is to get the work done quickly and in an organized manner (without getting bogged down in too many tasks), which would make Kanban the right choice.
Type of team
Scrum requires a teamwork community. It describes the roles of the developers, the product owner and the scrum master, who share a common goal - the finished end product. There are also benchmarks for the size of the team to ensure that they can work together optimally and complement each other's individual skills.
Kanban does not require a team structure and there may not even be a team with a common goal. Kanban just illustrates the workflow and uses WIP limits to avoid inefficiency.
The type of pace
There is a kind of agreement in Scrum that concerns sprinting. The requirements selected for the sprint are kind of "frozen" and have a fixed deadline with the sprint target - the increment. Changes are not intended and should be avoided so as not to jeopardize the increment.
Kanban, however, assumes that changes are possible at any time. It does not have to be adjusted to an iteration rhythm if a new requirement is to be worked on. Kanban is a pull system - the work to be done takes place immediately when the previous one is completed.
Of course - like everything in the Agile world - the choice between Scrum and Kanban is very context-sensitive. It depends on many factors, and this simple comparison is to consider the most common ones. It is worth trying both, to inspect them with regard to own project structures and also to consider hybrid forms. Like everything in this world also agile project anagement is not always black and white.