Scrum and Kanban are the most popular frameworks that belong to the same Agile family. Whereas Scrum likes rituals, clear roles and rules, Kanban is more of a free spirit, known for its pretty face (and effectiveness, too!). Which style feels closer to your heart? Which would you like to form close bonds with? If you are on the fence between the two, we’re here to give you a hand.
What is Agile?
Scrum and Kanban are both Agile frameworks, so they share a lot of features. Thus, before we can dig deeper into them one at a time, we need to stop for a while to discuss what Agile really is.
The answer will depend on whom you talk to. Product owners, developers, business analysts, or CEOs might perceive it in a different way. They might refer to Agile as a philosophy, mindset, way of thinking, or, more down to earth, a methodology.
Four Agile values
Agile followers live by four, let’s call them, commandments. Here they are:
- Individuals and interactions over processes and tools, so that you invest more time and effort in face-to-face communication.
- Working software over comprehensive documentation, so that you focus on project deliverables instead of creating lengthy papers.
- Customer collaboration over contract negotiation, so that customer success is your guideline along the way and you’re not blindly following the initial deals.
- Responding to change over following a plan, so that you are ready (and willing) to adjust to whatever happens.
The chief reason why Agile was created and became so popular is that the traditional methodologies, such as Waterfall, deliver value at the end of the project. Taking into consideration that it takes months or years to build digital products, waiting till the end of the way is definitely too long. Therefore, Agile focuses on delivering value faster, in smaller increments. This way you can test solutions, adjust, improve, deliver MVPs, get user feedback, start earning, gain funding, and so on. And on top of that, Agile welcomes changes with open arms, because they typically lead to improvements.
Waterfall approach
Agile is often contrasted with the traditional Waterfall methodology. The latter, linear approach means that you and your team can’t move to the next project phase unless you have completed the tasks from the previous one. It’s also difficult to go back, once something is done.
In Waterfall, you have to identify most of the requirements, analyse them, design, develop, implement a solution, and finally test if it all works. If you proceed step-by-step, you deliver value and get customer feedback really late. The problem is, that if you decide to make some changes, while already being in the last two phases of the project, it will take a lot of time and work. Basically, you need to go back to square one. Another thing, which may happen is that requirements have been understood differently by the client and the contractor/development team. Due to the nature of this linear methodology, you can make this discovery only at the end of the project. Waterfall doesn’t like changes.
Scrum methodology
Scrum is out and away the most popular Agile framework. In fact, when companies say they work in Agile, in most cases they mean Scrum.
Scrum cherishes roles and ceremonies, of which sprints come first: time-boxes wherein other events take place. What makes it highly effective is the/its transparency. All roles, responsibilities, and meetings are clearly defined, and everyone knows what other team members are working on at a given moment. If any disagreement arises, the team discusses the problem and resolves it TOGETHER.
Scrum roles
Roles and their responsibilities in Scrum are clearly defined:
- Product Owner: is responsible for product vision. S/he gets in touch with a client, understands their needs and project challenges. Based on this knowledge, Product Owner creates user stories and identifies priorities for the team.
- Scrum Master: assists the team, helps in their daily work and Scrum ceremonies, and removes project roadblocks. S/he is neither a project manager nor a team member.
- Scrum Team: is responsible for technical aspects and project execution. Everyone that works on the project belongs to this category, which means not only developers but also business analysts or UI designers, etc.
Ceremonies and events
Sprints are the essence of Scrum. A single sprint takes from 1 to 4 weeks. It consists of a variety of Scrum ceremonies and events which include:
- Daily standup meetings. Dailies are the 15-minute meetings that take place every day at the same time and place. At the meeting, every team member answers three questions: what they did yesterday, what they’re going to do today, and if there are any obstacles in fulfilling their tasks.
- Sprint planning meetings. The team thoroughly plans what they can deliver to the client in a given timeframe, that includes not only development but also testing, so the feature is ready to go live.
- Sprint review meetings. These take place at the end of every sprint when the team, product owner, and client discuss the progress and other issues to consider during the next sprint. It’s rather an informal meeting.
- Sprint retrospectives. During retros, the team discusses the last sprint in terms of what they did and didn’t do well, and what should be improved in the future based on lessons learned. The meeting should be treated as a safe space for everyone to share their thoughts, so there’s no room for blaming or criticising anyone.
- Backlog refinement. This meeting resembles workshops. Its aim is to add more details to the backlog once a sprint is underway.
On top of that, there are other terms that you will come across in Scrum: user stories, team velocity, Scrum poker, product backlog, product increment, the definition of ready, and the definition of done. But we won’t delve deeper into the terminology, as we can refer you to some of our more detailed articles in the subject:
Kanban methodology
Kanban is the next, after Scrum, most popular Agile framework. It is known best for its visual aspect, a Kanban board, which helps to understand workflows easily.
Kanban is a continuous process, there are no time-boxes or fixed events. Of course, you can have daily stand-ups and retros but you don’t have to, it depends entirely on you. The key metrics in Kanban are time-based: lead time and cycle time.
Roles and tasks in Kanban
Roles in Kanban aren’t defined, team members comply with their organisational roles. Also, they aren’t assigned the tasks, they simply pick the cards from the board depending on their skills, talents, or what they feel like doing at the moment.
In Kanban, there’s much room for companies and teams to lay down their own rules and policies on how to manage things. The key is to make the policies explicit and known to everyone concerned.
Kanban board
The project board shows the status of work in progress, so one look at it should give you an idea of how everything is going. Kanban cards contain information on tasks and they are grouped into three areas: to do, doing, and done. Usually, their hierarchy is set from top to bottom, beginning with the highest priority. Team members pick their tasks and as time goes by, they move them between three sections of the board.
Kanban boards can be physical, arranged with sticky notes, but online ones have become more popular. The reason for digital Kanban boards preference is the hybrid and remote work, requiring the dispersed teams to collaborate closely. Online Kanban boards can be created with a variety of well-known apps, such as Trello, Jira, or YouTrack (Agile Boards function), which we use in NeuroSYS.
WIP limits
Kanban concentrates on task completion. Too many tasks marked as in progress might indicate that the work is not proceeding or the tasks were put on hold. That is why Kanban limits the WIP, work in progress. A good practice to keep focus and get things done is to set WIP limits in your online Kanban board.
What is the difference between Scrum and Kanban?
Being Agile frameworks, Scrum and Kanban have a lot in common, such as task estimation and focus on delivering value in no time. But now it’s time to get your arms around their disparity.
The difference between Scrum and Kanban lies in a variety of aspects, more or less fundamental:
- Structure: Scrum is highly structured. All roles and meetings, including their duration, are clearly defined. Kanban is fluid and way less structured. There are no set roles, sprints, and meetings (if you don’t need them).
- Time-boxes: In Scrum, your work is divided into 1-4-week sprints. That’s the essence of the framework. With Kanban, the work cycles are fluid, you move from the to do tasks to the done section without clear breaks.
- Retrospectives: In Scrum, the discussion on what worked, what didn’t, and why, takes place after every sprint and constitutes its inherent part. In Kanban, you organise a meeting whenever you feel it would be good to talk things through.
- Tasks: Scrum tasks are assigned to the specific team members. In Kanban, it is team members that pick tasks for themselves and take ownership of the assignements.
- Roles: In Scrum, you’ll find team members with set roles. In Kanban there are no specific roles defined. Team members comply with their organisational roles.
- Teams: Scrum teams are cross-functional, they have all the competencies needed to carry out their tasks. In contrast, Kanban teams can be specialised, such as teams of testers or engineers.
- Metrics: The key metric in Scrum is velocity. It reflects the number of story points that are delivered in each sprint. In Kanban, the key metric is cycle time, which is the time that passes between the beginning of the task and its completion.
| AREA | SCRUM | KANBAN |
| Structure | Structured | Less structured |
| Time-boxes | Sprints | Fluid cycles, no set breaks |
| Retrospectives | After every sprint | When it makes sense |
| Tasks | Assigned to the team | Picked by the team |
| Roles | Specified | Non-specified |
| Teams | Cross-functional | Cross-functional or Specialised |
| Metrics | Velocity | Cycle time |
Is Kanban better than Scrum?
And is an apple better than a pear? This is a similar type of question.
Or, as our Managing Director would answer, IT DEPENDS. It depends on your organisation, team composition and its members’ experience. Naturally, personal preferences play an important role as well.
The fact is that organisations which have already started their Agile journey, in most cases have begun with Scrum. The framework offers structure and a set of rules that are helpful, especially at the beginning. Starting straight away with Kanban might feel more like throwing yourself in at the deep end. But it doesn’t have to be this way. Kanban can be a made-to-measure approach, particularly when increment of work isn’t linear and the project has to pick up speed first, before it will be monitored and managed.
Generally, if matters like cyclical delivery of increments, tools for work planning, customer engagement, transparency, and retrospectives are important to you, you should go for Scrum. Meanwhile, Kanban works perfectly during maintenance periods when the system goes through end-to-end tests or is streamlined, or technical debt is being paid off. In situations where work is hard to plan, Kanban is a perfect match.
To give you food for thought, Kanban doesn’t have built-in retrospective mechanisms. Thus sometimes it is difficult to give a sense of purpose and success, to the team and clients. Scrum secures that thanks to cyclical events and clear sprint goals.
For those who are still undecided or like both options equally, there is something in between, a framework called Scrumban. It is a blend of Scrum and Kanban, taking the best practices out of each. For example, in Scrumban you use the Kanban board but also have mandatory daily meetings.
As you can see, it isn’t a black-and-white choice to make. We can’t categorise the projects as Scrum- and Kanban-prone just that easily. What we can suggest here, is to use Scrum/Kanban as logic dictates, taking into account the above-mentioned benefits but also limitations.
Scrum vs Kanban wrap-up
We can’t praise Agile methodology enough. No matter whether you choose Scrum or Kanban, Agile’s focus will be put on software quality, effectiveness, constant improvement, great results, and trust in people. Simple as that but most importantly working.
Bob’s your uncle, we’ve reached our destination. But what a journey it was, right? At the end of the day, the choice of the framework is yours, though we hope we’ve managed to help you out. If you’re still in two minds about it, let us know. We can give you a helping hand during free consultations.
