If you are part of the IT crowd, you probably often get to hear about the ongoing Scrum vs Kanban debate saga. We all would like to find a ‘magic pill’ method that would turn us into hyper fast and super efficient folks who can create solid project schedules, get estimates right on target, fix bugs instantaneously, make split-second decisions, speed up release, stimulate work process optimization, drive high efficiency, increase team member engagement, and make the project run smoothly. But before that magic formula is invented, we’ll have to make do with the existing tools and techniques.
If you are in the product development business, one of the decisions you’ll have to make from day one is which project management framework to adopt. Scrum and Kanban are two trending methodologies, both related to the Agile family, but different in many ways. And then, there’s also Scrumban (Scrum-who, you ask?) – a hybrid approach, which is basically a mix of the two, incorporating Kanban and Scrum best practices. While Scrum has been around for quite a while, Kanban hit the market of PM products as recently as the late 2000s and, naturally, raised eyebrows of many agile practitioners wondering why in the world they would need to move from the tried-and-true Scrum process to a new and unknown Kanban method.
You may be racking your brains now, trying to figure out the differences between Kanban vs Scrum and what might make one or the other a better option for you. How do they stack up? Why and when should you go for Scrum or Kanban? How can you balance your project needs with the strengths of each methodology and choose the path that would work best for your environment? Let’s explore some of the diversity between Scrum and Kanban.
Why Scrum
When eating an elephant, take one bite at a time
When Scrum software development comes to town, it may be a bit of a shock to the system for teams used to traditional methods like Waterfall, where they work independently on big chunks of a project. It’s not rare, though, that they later have a hard time putting those big pieces together. In Scrum you have self-organizing teams committed to sprint goals, small manageable parts of the product, that project participants anticipate they can complete during a 1 to 4-week iteration. The team then integrates new features into the bigger project. The Scrum Board is a tool that helps you visualize the workflow and measure your rate of progress by breaking all work down into small deliverables called ‘stories’. Each story is moving along the board from the Backlog (the to-do list), into WIP (work-in-progress), and into completion (done).
Staying on the same page
Constant communication is one of the guiding principles of Scrum development methodology. There are four types of meetings in Scrum: sprint planning, daily Scrum, sprint review, and sprint retrospective.
A sprint planning is the first meeting to kick off a new sprint. You have a bunch of features to implement, so you as a team need to plan roughly how long it will take to build them, and come up with a sprint backlog. The point is to get into a more predictable pattern of delivering a software product. All specs are agreed upon before the sprint begins and can’t be reset until it finishes. It’s only when the sprint comes to a close that you can wipe the slate clean, and start a new one. With daily stand-ups, short cycles, and continuous feedback from business, issues are easier to identify and resolve on the spot.
At the end of each sprint, project participants meet up with stakeholders (users, customers, and managers) to host a demo of a potentially shippable product, receive insights, and make sure the backlog is ready for the next sprint. Based on suggestions for what features to ship next and input on priorities offered by stakeholders, you may remove irrelevant story points, create new stories, prioritize them, or split them into smaller tasks. As a team, you may retrospect on your performance, and talk about how Scrum is working for you, and what needs to be done differently in the next sprint to move the product toward launch.
This structure (and discipline) brings more transparency, accountability, and flexibility to a development process, pushes team members to continuously improve, and helps everyone to be on the same wavelength – everybody knows who is doing what and what the next steps are going to be. Ideally, missed deadlines will help the team learn how to plan sprints more accurately. Any failure will be accepted as an opportunity to learn and improve. Scrum is not about pinpointing mistakes, it’s about discovering the best way to do things.
Everyone does everything
Scrum development methodology emphasizes team collaboration. Instead of traditional roles, the team follows a set of Scrum roles: the Product Owner, the Scrum Master, and the Development Team.
The Product Owner is a visionary and motivator who casts the vision and communicates goals to the team, focuses on the client requirements, writes user stories, builds and manages the Product backlog (a prioritized list of all features of the product), and interacts with other stakeholders to keep the process on the right track.
The Scrum Master acts as a coach and facilitator for the team, overseeing the Scrum process and assisting team members in focusing on the core product development activities. He initiates meetings and works with the Product Owner to get the product backlog ready for the next sprint. The Scrum Master also plays the role of a problem solver, eliminating any roadblocks in the path.
The Development Team decide what work they can complete in each sprint and collaborate with the Product Owner to negotiate the scope of the sprint backlog. There are no distinct roles on the team (like a designer, developer, or tester) – they all help each other and work together towards delivering a goal. Everyone pitches in, feels involved and knows that their input counts.
The Scrum Dream
Scrum software development model works well for large complex projects accompanied by many changes, adjustments and improvements along the way. Scrum easily accommodates new requirements throughout the whole process. It also helps you keep sight of the big vision and not get sidetracked by dozens of little distractions that pop up every day. Scrum gives you a roadmap, helps you keep your destination in mind and say ‘no’ to all those little showstoppers. You focus on the big goals first and save small stories for the end. Scrum is a good match for projects where continuous feedback is required, software needs to be delivered on the regular basis, and there’s no fixed release date.
The Scrum Reality
Even though switching your organization to Scrum development methodology is a beneficial process, you may also face many challenges if you choose to use Scrum. First up, each and every team member needs to be trained to use Scrum efficiently. Because there are no defined roles, everybody needs to have good technical knowledge and expertise. Also, if the Scrum Master doesn’t trust people and tries to control them, this may ruin literally everything. What’s more, all project participants need to stay on the team throughout the entire project.
Because there is no completion date, projects can run the risk of the scope creep. Some clients will never stop when it comes to additional functionality. Estimations won’t be accurate if goals are not well defined up front and there are lots of uncertainties. Although Scrum teams provide estimates themselves, you still often feel pressed by very short time frames. The pressure to meet tight deadlines places too much of a burden on the team’s shoulders and makes you slog it out during the last few days of the sprint. Guess what happens next? Yep! Burnout on the team. Next? Productivity crash.
Scrum tends to create unnecessary overhead – you often have to sit through time-consuming sprint planning meetings full of lengthy discussions of features and endless debates over issue priorities. And then, there are even more meetings – ‘grooming’, daily stand-ups, reviews, retrospectives, again planning, and it goes on and on. It makes all of your team feel swamped, frustrated and stressed out.
To cap it all, unexpected issues often come up during the sprint that prevents the team from delivering the stories in the sprint backlog. What if a high-priority bug fix is necessary? Or a customer’s sudden change of heart makes the team reconsider a couple of features? Or some issues turn out to be more serious than they first seemed? Changing commitments in the middle of a sprint makes the whole process even more complicated. While there is always room for negotiation with the Product Owner to make sure that all these blockers and distractions are taken into account, the team may still feel like losers, because they have screwed up their sprint goals. Result? Everyone’s morale suffers.
Naturally, many teams and organizations begin to look for alternatives. That’s when Kanban steps in.
Why Kanban
See the big picture
Who of us hasn’t used those different color post-it notes as a reminder of top items on our ‘to-do’ list? The office wall studded with sticky notes might look like madness, only until you come to realize there’s a method behind the chaos. Kanban development methodology helps you visualize the workflow and see the big picture of the team progress. By making the work visible, you can also identify and remove issues early on, and take a more holistic system-level view of things. Kanban best practices enhance continuous collaboration and improvement – engineers are encouraged to work as a team and increase the quality of work.
In Kanban, each status of a task (To Do, In Progress, Done) is represented by a column on the virtual board. ‘In Progress’ section may be expanded and have ‘analysis’, ‘coding’, ‘testing’, ‘for approval’, and ‘ready for release’ columns. Every work item has to pass through all of those stages. Kanban cards (like post-it notes) feature information about a specific task – a brief description of a work item, who is doing it, technical specs, and so on. As the work progresses through different stages, the story is moving accordingly – from left to right. It allows everyone on the team to know the status of each project component, spot blockages, implement changes, and improve the workflow.
The Kanban board can also help you steer your team discussions. You simply go through the board to look for items that haven’t moved since the last meeting and discuss with your team what is standing in the way of progress. You can track how long a card sits in a queue before it starts moving, how long it takes to get from the backlog to being done and how many tasks get completed each day. With Kanban software development, you can really see the project from a larger perspective. It also fosters your team decision-making that naturally flows from that shared understanding of what to do, when to do and how much to do.
Less is more
Multitasking is an efficiency killer. Period. Kanban development methodology drives productivity and velocity by putting a cap on WIP (work-in-progress). In other words, a team is only focused on the most important work items that are actively in progress. Once you complete your current task, you grab the next prioritized card from the top of the backlog into the WIP. If a state reaches its pre-defined WIP limit, no new work can enter that state. It can only be added when a new slot opens up. Limits will force you to stop multi-tasking and fix any bottlenecks down the road. Those stories that got stuck in a state will pile up on the board for you to visually see what holds the process up and where it badly needs improvements. It encourages the entire team to clear up the cluttered states to be able to move on, thus reducing the overall cycle time, the average time it takes to get something done, and making it as small and predictable as possible. Let’s put it simply, you do more with less. Finish what you are already working on before you take on more work. Work is done. Let’s get things rolling again!
The Kanban Dream
Kanban software development is a fluid model that allows you to add and reprioritize stories on the fly. While Kanban gives the ownership over the backlog to business, it’s the engineering that owns the rest of the process. It minimizes tension between business and engineering and saves the dev team from having to deal with last-minute or mid-process changes. Kanban’s power comes from its ongoing focus on software quality, reducing any wasteful activity or context switching, and creating maximum customer value. The Kanban technique fights any temptations to cut corners and skip some important steps in the process.
Kanban’s visual nature makes it extremely easy to understand, so you need no training to start using it. Visualization also helps you to quickly expose bottlenecks and optimize the throughput. Kanban can be seamlessly implemented into a process that is already running. The idea is to start from where you are currently, and gradually make updates and changes to adapt those processes and further improve the project delivery. Kanban may be a life-saver if your team doesn’t respond well to massive shifts, and everyone feels completely wiped out seeing no big results in the short-term. With its upbeat, forward-looking feel and small accountable progress, Kanban allows things to move smoothly towards the overall process improvement.
Kanban is best suited for work where you have to quickly do some small tasks (like squashing bugs), requirements change often and fast, or the team is in the maintenance phase with changes needed to be made asap.
The Kanban Reality
Kanban is not without its problems. Kanban development methodology is … not really a methodology. It’s more of a technique that is rather loosely structured and so may not be the best option for new teams that typically need a more prescriptive approach. It’s also very linear – a good match for maintenance work, but not quite relevant to a complex product development process.
In Kanban you should be committed to keeping the board clear and up-to-date, otherwise, there might be a lot of confusion in work. Once the board gets messy or overcomplicated, using Kanban may become a very negative and discouraging experience. You will also want to hold regular retrospectives – even though not required by Kanban but recommended for teams to reflect and improve.
There is a common complaint about Kanban that you never know when the task is expected to be finished. The columns on the board represent stages, but you can’t really tell how long each phase is going to last, because there is no defined time frame. Planning and urgency are no biggie here – a stark contrast to Scrum software development, where a focus on timing is almost always the case.
Scrum vs Kanban Comparison
In the Scrum vs Kanban dispute, you will discover that both Scrum and Kanban are unique and powerful methodologies that emphasize product quality, continuous improvement, and efficiency for business. We have summarized the differences between the two approaches in the following table. It should help you find the sweet spot for your team and project.
| Scrum | Kanban | |
|---|---|---|
| Kanbanboard vs Scrum board | Sprint Planning When planning sprints, the team will make estimations of stories and decide which story goes into which sprint. The board shows whether the stories are in plan mode or work mode.Board life-time Scrum board is reset after each iteration and prepared for the next sprint. Board ownership Agile Board Reports |
Workflow No planning is required. The team simply moves through the flow of the Kanban board. If the workflow changes, columns are added or removed as needed.Board life-time Kanban board is persistent. No need to reset it. It will continue to flow as long as the project lasts. Board ownership Constraints Reports |
| Cadence | Timeboxed iterations. | Continuous flow. |
| Prioritization | Setting priorities are strictly prescribed. It includes sorting and grooming of the product backlog, estimation of resources and deciding on priorities for the next iteration. | Prioritization is mainly optional with the exception of the backlog that should be prioritized. |
| Delivery timelines | Deliverables are determined by sprints. | Continuous delivery on a just-in-time as-needed basis. |
| Team | Small and cross-functional teams are recommended. | Small, medium or large teams are allowed. Cross functional or specialized. |
| Roles | Product owner, scrum master, development team. | No pre-defined roles. The team is encouraged to collaborate and help each other. |
| Estimation | Scrum stresses on estimation. | No requirements for estimation. |
| Key metrics | Velocity – the amount of work delivered in an iteration. | Cycle time – the end-to-end time it takes to complete a work item. |
| Item size | Small items doable within a sprint. | No specific limits on the volume of the task. Similar size work items. |
| WIP limit | WIP limited for each sprint. | WIP limited for each workflow state. |
| Modifications / Changes / Updates | Changes during an ongoing iteration are frowned on and discouraged. The number of stories is set during planning session before the beginning of a sprint. | Changes can be introduced at any time, as soon as the capacity is released. |
| Ease of use | Too complex to set up, especially for new users. | Much easier to start with. Simple and straightforward structure and rules. |
| Best applications | – Product development – Projects with relatively stable priorities – Large-scale complex projects with an extensive number of issues – The need for a thorough, project plan and detailed tracking of the progress. |
– Support/Maintenance work – Projects with floating priorities – Small-scale projects with a limited number of issues – The need to start working quickly with minimal configurations. |
Final Thoughts
When considering Scrum vs Kanban, there is no definite winner. Both methodologies work well. Neither is a magic pill. Some teams are fine with Scrum, while others feel more comfortable using Kanban. There are a lot of scenarios, where Scrum may be a better choice. The same is true for Kanban. To be able to choose the right tool, you really need to understand the context of your project, your business and development goals, and the specific job at hand. It might also be a good idea to explore best practices of both, experiment, and decide what is best from each approach that your team could use. The answer may lie somewhere in the middle. If creating a hybrid would mean better team synergy and improved productivity, then go for it!
READ ALSO
Write your own
success story
with Pwrteams!
