Scrumban: Choosing the Middle Ground Between Scrum and Kanban

After the Agile Manifesto made its way into the software development consciousness, Agile methodologies began emerging, seeking a way to put the values and principles of Agile into practice. These methodologies include Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development, Agile Unified Process (Agile UP or AUP), Crystal, Kanban, and Dynamic Systems Development Method (DSDM).

Each method has strengths and weaknesses and each meets the needs of developers, but with subtle differences. As Andy Kyte, David Norton, and Nathan Wilson, all of Gartner, explain in the 10 Things CIOs Need to Know about Agile Development: “In most commercial and public sector organizations, the application portfolio will present many different classes of development problems, some of which will be well-suited to agile, while some may be better-suited to incremental, iterative development, and some to a modified waterfall model. Agile is not "better"; it is simply better-adapted to some problems, but not so well-adapted to others.”

Currently, Scrum is the most popular Agile methodology for software development. However, Kanban has become widely employed for maintenance projects in which an end game is not necessarily the goal of the project, but rather ongoing development without reliance on a clearly defined backlog. This article will discuss how Scrumban has become the middle ground between the Scrum and Kanban Agile methodologies. In order to fully understand Scrumban, you should have a complete understanding of Scrum and Kanban.

Don’t miss the latest tips, best practices, templates, and more in our Project Management Resource Center.
Get All the Resources

Scrum: The Advantages and Disadvantages

Each methodology comes with advantages and disadvantages. Scrum is an Agile methodology that employs small teams working collaboratively in short development periods (sprints), to deliver working software at the end of each time-boxed sprint. Scrum deliberately short changes the planning process, focusing on rapid development of working software in smaller pieces. Some of the advantages of Scrum include:

  • Improve scheduling - Scrum overcomes the issue of complex business requirements that are hard to understand and that make scheduling difficult. The Scrum approach to evaluating requirements is to break them into consumable bites that are developed rapidly.
  • Reduce impact of errors - Errors that may be made in one Scrum are rapidly reworked and repaired in the next Scrum.
  • Improve communication - Daily meetings ensure status updates (progress and stalls) are highly visible. In fact, management of development can be reduced to using a task board, in which the Sprint backlog is listed in a table along with columns denoting status.
  • Increase productivity - Daily meetings increase team productivity.
  • Build better customer relationships - The iterative nature of Scrum means customer involvement and feedback is important, and that makes the team more aware of the customer needs and the team, in turn, can be more responsive to those needs.
  • Improve software - Change is not an interruption but a means to improve the value of the software.

Conversely, some of the disadvantages of Scrum include:

  • Scope creep - Without a defined end to a project, and with change embraced so gladly, scope creep becomes a real problem. Stakeholders are often tempted to add more and more functionality.
  • Not ideal for large teams -Scrum works best with a small team.
  • Inexperienced team members can be a liability - Successful implementation of Scrum depends on team members being able to estimate development time.
  • Poor fit for micromanagers - Scrum works best when the Scrum Master can rely on the team without being too controlling. Scrum is about individuals managing their work together, not receiving heavy oversight.
  • Turnover can be enormously adverse - The small team size and the shortness of the development periods can be taxing.
  • Quality management is more difficult - Team members perform all testing, but regression testing is sometimes left out of the loop, resulting unit testing being the only testing performed.


What is the Kanban Methodology?

Kanban, developed by Taiichi Ohno, an engineer at Toyota, is defined as a method for managing and improving service delivery gradually over time. There are three guiding principles of the Kanban method:

  • Start with what you do now
  • Agree to pursue incremental, evolutionary change
  • Respect the current process, roles, responsibilities, and titles

There are five core properties of Kanban:

  • Visualize the workflow
  • Limit Work in Progress (WIP)
  • Manage flow
  • Make management and process policies explicit
  • Continuous improvement, also known as Kaizen (using models and the scientific method)

Kanban: The Advantages and Disadvantages

Just like Scrum, Kanban has its own advantages and disadvantages. Some of the advantages of Kanban include:

  • Improve resource allocation - WIP is limited, so that new work is pulled into the team as resources become available.
  • Simplify project management - The Kanban board provides an at-a-glance visualization of the state of all work, enabling easier project management.
  • Reduce interruption - Change is less radical because you work with the processes you have and improve them over time.
  • Make more informed decisions - Visualizing the workflow makes it easier to understand how work proceeds and makes decisions on changes easier.

Some of the disadvantages of Kanban include:

  • Kanban boards must be current - An outdated Kanban board can cause big problems. Kanban relies on team members to keep everything up to date, and lacking the daily meetings of Scrum, this can be harder to do.
  • Making a Kanban board overly complex - When there are too many items or process being tracked on a Kanban board it can lead to confusion and make it difficult to accurately update.
  • Lack of deadlines: Without timeframes for development, the team can fall behind

Scrum and Kanban: How they Differ

Scrum and Kanban are very different. It may seem impossible to reconcile them. Scrum has a set of prescribed roles including the Scrum Master, the product owner, and the stakeholder. Conversely, Kanban has no prescribed roles. Both Scrum and Kanban are viewed as “pull” systems meaning team members pull features from the backlog as they become available to work on them. Another perspective is that, because of the “batch” character of the backlog, Scrum is really a “push” system, in which a set of features are assigned to the team at the beginning of the Sprint. Kanban is regarded as an undeniably pull-based system in which features are continuously pulled from the backlog as needed.

Scrum has a daily meeting and several required meetings, such as the demo in which the software is revealed to the customer for feedback. Kanban has no required meetings.

Perhaps the most striking difference between Scrum and Kanban is that, while Scrum is constrained by the length of the Sprint, Kanban operates without a time limit for development. There is no defined beginning or end, but rather a continuous flow of work, with every successful development being followed by the start of new development.

Although Scrum is meant to be easy and flexible, some development teams find it to be too rigid for their agile business. At the same time, they find Kanban to be too lax. Scrumban was born as a middle-ground between Scrum and Kanban – the rigidity of Scrum combined with the more lenient Kanban has become a perfect method for many agile organizations.

Scrumban Methodology: The Best of Both Worlds

Scrumban was introduced by Corey Ladas, a software development methodology enthusiast, in his book, Scrumban: Essays on Kanban Systems for Lean Software Development. He asserts that Scrumban was created as a means of transitioning a development team from Scrum to Lean (relies on a build, measure, learn flow for continuous improvement and focuses only on what brings value to customers) or Kanban. But while the intent was for teams to replace Scrum, it has become a methodology all its own, combining elements of both Scrum and Kanban. The decision to replace Scrum or Kanban with Scrumban should be made in response to the environment and organizational needs.

Scrumban is most commonly used in development and maintenance projects. In practice, both development and maintenance teams need many of the same skills. Development teams need a means of managing their entire development process, while maintenance teams must be able to make updates and repairs to faulty software.

Comparison of Scrumban to Scrum

  • Iterations: The iteration is the defining characteristic of Scrum, whereas Scrumban takes the Kanban approach of continuous workflow - with iterations being optional.
  • Team roles: Scrum has defined roles with development team members wearing all the hats of a development project , whereas Scrumban only requires roles as needed.
  • Visualization: Scrum can use a board, but is mostly dependent on backlogs and burndown charts, while Scrumban, like Kanban, is dependent on the Scrumban Board for maintaining visibility into the work.
  • Meetings: Both Scrum and Scrumban hold daily meetings, but there are no Sprint or release planning meetings and retrospectives in Scrumban. Scrumban embraces on-demand planning.
  • Estimating: Scrum teams must estimate (oftentimes using the bucket-size planning system and story points) the time work takes in order to meet the commitments of a Sprint, whereas Scrumban doesn’t have a time constraint. Instead, estimating becomes apparent over time as the team accomplishes more tasks.
  • WIP: The Scrum WIP is defined entirely by the Sprint backlog and planned at the start of each Sprint, while the Scrumban team limits the WIP to the available resources.
  • Change: Change is welcomed in Scrum because it can be responded to and planned in a subsequent Sprint, but in Scrumban change is responded to instantaneously. The lack of Sprints and backlogs means there are no limits to when tasks can be introduced. Change becomes a matter of a resource becoming available to take it on.
  • Feature Freeze: Although Scrumban responds to change instantaneously, there is a limit. Scrumban adopts feature freeze - a cut-off time where changes or additional features cannot be added because the project deadline is approaching.
  • Triage: Since Scrumban does not embrace estimating, the triage stage is critical. As a project deadline approaches, Scrumban triage enables the project manager to terminate work on less important features in order to complete essential features on time.

Comparison of Scrumban to Kanban

  • Team roles: Kanban has no prescribed roles, but in Scrumban there is a definite team and may have required roles.
  • Meetings: Kanban does not require meetings, but Scrumban consists of daily meetings. Daily meetings help to maintain the collaboration between team members and to overcome impediments to progress. In addition, while Kanban is about an evolving process, there are no prescribed meetings to examine the evolution or proposed improvements. Scrumban allows for post-mortems that enable the team to work on process improvements and for team members to share what they learned from the work.
  • Metrics: Both Kanban and Scrumban rely on measuring lead time and cycle time (sometimes used interchangeably) as their key metric. This metric estimates the average time it takes to complete a specific task. Lead time is what the customer sees from the time a request is made to delivery. Cycle time is the time from the work beginning to delivery.

What is the Best Environment for Introducing Scrumban?

You may be wondering what environment is best for introducing Scrumban. As with all methodologies, Scrumban is not for every environment or culture. If your organization is optimally suited for Scrum, with many experienced members, customers who want to participate in the development process, a clear understanding of user stories, and your corporate culture is one where defined project management and timelines are highly regarded, you may want to stick to Scrum. If you are primarily operating in a maintenance environment in which new development is a small part of the team’s activities, the work is ongoing, pulling tasks as needed is important, and there are no projects defined for specific customers, you may want to stick to Kanban.

The best time to implement Scrumban is when:

  • A project has a great deal of unexpected change to user stories and reworking of priorities.
  • You want to add pull features to the Scrum development process.
  • Scrum has been unsuccessful due to any number of issues or because there are not enough resources to meet the time constraints of Scrum.
  • The work is event-driven, such as help desk support, where priorities shift constantly.
  • The team is entirely focused on adding features and supporting an existing product.
  • Scrum is utilized by your development team, but you are interested in some principles of Kanban.
  • You find some of the rigidness of Scrum limits your team’s ability to adapt to change.
  • You’re transitioning to Kanban, but need to make small methodology changes in order to limit disruption.

The final word on Scrumban is always going to be how the team responds to the method. Scrum works well for teams that like more structure and want to know what they will be working on tomorrow. The main benefit of Scrumban is the fluidity of the model. In the end, as is the case with any development methodology, company and team buy-in will determine success.

Why Smartsheet is an Effective Tool for Scrumban

Smartsheet is a spreadsheet-inspired task and project management tool with powerful collaboration and communication features that are essential for Scrumban project management. Like Scrumban it marries the best of traditional project management features with the visualization tools that are at the heart of Kanban. Use the familiar spreadsheet like interface to prioritize user stories, manage product backlogs, and update Sprint status. Easily switch between spreadsheet, Gantt, and Calendar views to manage project details. Use Card View for a highly-visual representation of a Kanban board.

Card View enables you to focus attention with rich cards, provide perspective with flexible views, and prioritize and adjust work. Display information on cards including custom fields, images, and color coding to better focus your team’s attention. Categorize cards into lanes to organize your work more visually. Intuitively change lanes and filter cards to track the progress of Sprints. Act on tasks and change status of work by dragging and dropping cards through lanes to immediately share decisions with the entire team. Get started with a pre-built template for your project type, or import existing projects directly from Trello.

Project managers and team members appreciate the collaboration and communication tools. Since Smartsheet is a web-based app, stakeholders can check-in on a project status anytime from virtually anywhere. Users can store all project elements in one convenient location, and project managers can schedule automatic alerts for when tasks are falling behind.

See how easy it can be to use an agile project plan template and manage projects. Try Smartsheet for free for 30 days.

Try Smartsheet For Free

Want more project management tips and best practices? Check out our Project Management Resouce Hub for the latest articles, templates, and more!

Add new comment

Our Privacy Policy describes how we process your personal data.

By submitting this form, you accept the Akismet privacy policy.