Kanban vs. Scrum vs. Scrumban for Agile Teams

Agile software development stems from a simple philosophy: being agile means creating applications using a process that responds well to change. Thus, Agile means the ability for a software development team to adapt to change without missing a beat or dissolving into chaos.

Being Agile means working together as a team built with diverse capabilities, skills and talents. Team members include both the business and software development teams collaborating to produce working software that meets or exceeds customer expectations. Agile success stems from delivering high-quality, functional software to customers rapidly, continuously or in short sequential release timeframes.

The Agile methodology includes a manifesto and a list of 12 principles, which intend to steer software development teams in a positive direction while accepting and adapting to changes. Agile software development teams work together collaboratively and change processes and procedures with the shared goal to improve both the software and the development process.

As part of Agile software development, there are generally three standard options for managing team tasks and work progress:

• Scrum

• Scrumban

• Kanban

Each of these approaches is considered Agile, and they cover a variety of working situations. So, what’s the difference between Scrum, Scrumban and Kanban? Which one works best? And do you have to select one and stick to it? This article defines and compares each option and discusses how to choose one for your unique organization.

What are Kanban, Scrum, and Scrumban?

Kanban, Scrum and Scrumban all use a manual or an electronic board to track work. The boards display varying columns determined by the team. Each column represents a business process task or function. Most software development projects contain these or similar task-based columns to track and visualize work:

• backlog

• to-do

• development

• QA testing

• release or done

Each of these task columns represents a chunk of work that needs completed for the project or release. The team creates and stores user stories in the backlog until they are reviewed and moved into the to-do column for work to begin. Tasks move through each column as the development team completes the work, until the feature is considered done. The definition of done varies by team, either the feature is done when all related code is committed and tested, or the feature is considered done when it's released to the customer.

Kanban, Scrum and Scrumban differ in the time allotments for this work and the meeting requirements.

Scrum manages work through planned sprints or iterations, generally lasting 1-4 weeks. Each sprint begins and ends at set times and conforms to established deadlines for work completion. The Scrum board resets at the beginning of every new sprint. All completed work is archived within the designated sprint. Unfinished work typically rolls into the next sprint, moves back into the backlog or changes to a defect. Scrum teams tend to follow the daily standup, review and retrospective meetings at precise times during the active sprint.

Kanban does not have pre-defined iterations or set time-based deadlines. Kanban work flows continuously across the board until the release work is completed. At that time, the team determines if the release is finished and then starts over with a new iteration. Work managed in a Kanban board remains active on the board but is typically moved off to a storage location by release version. Kanban teams also have planning, standup and retrospective meetings as needed.

Scrumban uses the defined and time-boxed sprints of Scrum in short, planned iterations that typically last from 1-4 weeks. The board resembles more of a Kanban approach where iteration work flows continuously across the board. Scrumban teams follow the Kanban approach to having planning, standup and retrospective meetings, but only as needed. Scrumban typically enforces stricter process rules like Scrum while also using the continuous development approach of Kanban. Essentially, Scrumban is Scrum with more freedom around meeting necessity and column or work movement rules.

Kanban vs. Scrum

Kanban is a low-stress version of Agile work management. Work tasks move across the board based on team rules, but without the stress of a time-boxed deadline. That said, all software development includes some type of deadline. For Kanban, established deadlines are typically based on feature release dates. Releases might be weekly, daily, monthly, quarterly or any time in between depending on the customer’s needs. The team continues working until all planned stories are completed, including design, coding and testing.

With Kanban the team decides what meetings to hold and the frequency. Kanban teams do not require daily standups, design or user story reviews. Retrospectives might occur at a set time, if they are not necessary.

Conversely, a Scrum team meets daily for standups. Additionally, the team meets for design or backlog reviews prior to the start of a new iteration, and meets again for a retrospective after the sprint ends. The meetings themselves are Agile, in that they are typically short and to the point. The team plans the iteration work that can theoretically be completed within that period.

Most Scrum teams iterate weekly or every two weeks, which holds them to meeting specified deadlines.

The problem with Scrum is, when tasks are not completed or moved to Done, they typically roll over to the next iteration. The result is often a constant waterfall of work flowing between sprint iterations. Each team decides how to handle uncompleted work. Many teams move uncompleted work to the next sprint, the backlog, or change it to a defect. The Scrum focus is on finishing the iteration on time with working, releasable code. Some teams may release at the end of each week; others will build the work up and release after a known set of sprints. Many development teams execute four or five sprints and then release — this approach tends to allow more time for QA testing and for customers to prepare for an update.

Scrumban vs. Scrum

Many people see Scrumban as a more relaxed version of Scrum. Likewise, Scrum is the rule- and deadline-focused version of Scrumban.

With Scrumban, work is released in planned cycles like Kanban, either at a set time or after a defined number of iterations. Scrumban teams tend to use WIP (work in progress) limits on each column. When the WIP fails below a defined threshold, the team meets to pull in more work from the backlog. Scrumban enables team members to complete higher priority work first through prioritization. Scrumban exposes bottlenecks in the development team’s workflow so they can be addressed when they occur.

Scrum teams often experience scope creep when tasks flow to the next iteration or user story functionality changes in the middle of a sprint. Scrum team flow can easily run off the rails with late changes after the stories are planned and in work.

Scrum teams tend to enforce the meeting requirements discussed above, which can take away time from productive work on tasks. This is especially problematic when sprint work must be completed within strict deadlines. Many teams take several sprints to adjust to Scrum, so it can be helpful to plan time for teams to adjust to sprint timing and meeting needs.

Scrum is useful for development teams using continuous deployment in short sprints with small numbers of user stories. But, keep in mind, the user stories must be small and independent to be releasable at the end of each sprint. Scrum team product members must ensure user stories are specific and self-contained to ensure productive flow from development to testing to release.

Kanban vs. Scrumban

Scrumban came about as a compromise between Kanban and Scrum.

In Scrumban, teams work in iterations, but the meeting requirements and deadlines tend to be more flexible and adaptable, like Kanban. Scrumban teams tend to enforce WIP requirements between columns more rigorously than Kanban teams.

The focus of a Scrumban team is on completing tasks within the iteration. In contrast, the focus of a Kanban team is on completing work in a timely manner within release but not sprint deadlines. Ultimately, the choice between one or the other likely depends on how regimented the organization or team would prefer to be when it comes to sprint deadlines.

How to choose an Agile methodology

One of the most useful aspects of Agile is the ability to change and adapt. When choosing a task management process, start with the one you think best meets two criteria: the team’s working habits and the end user’s needs for release updates.

Consider how often end users want a new release. Do they want rapid updates? Do they also need to test the release before it goes to production? If so, frequent releases may be overwhelming, or they’ll simply choose a release when it suits them. How does the end user approach affect the application?

When choosing an Agile methodology that’s right for the team, plan for a trial-and-error period. Use the Agile continuous improvement process to make the changes necessary for the software development team to work effectively and produce a high-quality application release. If necessary, create an Agile approach that works for your team. Try out an approach for a month or two, and determine what works best for your team.

Each business, organization, team, customer and worker functions differently. Make the selected Agile task management system work for all parties involved.