What is Scrumban?

Scrumban is a hybrid of Scrum and Kanban - a mixture of Scrum’s ceremonies, with Kanban’s visualization, WIP limits, pull system, and continuous flow. A combination like this is particularly useful for companies transitioning from Scrum to Kanban, or those that have never tried Agile but are interested in moving to a pull workflow.

The term Scrumban was coined by Corey Ladas, the author of “Scrumban: Essays on Kanban Systems for Lean Software Development”.

Scrum and Kanban in a nutshell

Scrum was developed as a framework for simultaneous engineering in the software industry. Its goals were an increase in the speed of product delivery and a higher ability to respond to changing requirements and market conditions. Scrum splits work into 1-4 week iterations called sprints, after each of which there should be a working product available. In Scrum, teams are small and cross-functional, and the entirety of work for a given sprint is selected by a product owner.

Kanban has its roots in manufacturing, and one of its key features are WIP limits. Teams using Kanban focus on maintaining a continuous flow of work, visualized as Kanban cards on a board split into work stages. Each stage has its designated WIP limit, helping to manage throughput, monitored regularly to ensure process efficiency and predictability.

What is Scrumban?

The Scrumban hybrid allows teams to make the best of both worlds, to meet their specific needs. It’s often recommended that mature teams move from Scrum to Kanban, and Scrumban is a good way to complete this transition, though often, teams choose to simply remain in Scrumban. In a way, Scrumban is more aligned with Kanban than with Scrum, in the sense that it’s easier to apply to various applications, given that it’s less restrictive than Scrum.

The origins of Scrumban: Adopting Scrum is hard

Transitioning to Agile is hard for most teams. It often requires a mind-shift change, that can be difficult to grasp. Also, due to the popularity of Scrum, many managers think of Scrum alone, when they think of Agile, despite there being numerous other (potentially easier to adopt) frameworks available, i.e. Kanban, XP, DSDM, etc.

Although there are many success stories around teams who have implemented Scrum, if you could speak to those teams, they would likely tell you that achieving success with Scrum has not come easy. For the most successful companies, it often took 12 to 16 weeks to develop a discipline to make Scrum work. It’s common for companies to require serious outside consulting help with this. Businesses often struggle with finding the new required roles of product owner, scrum master, and development team. For many, this is a bit of an HR disaster.

Furthermore, calculating story points and measuring velocity - while not required as part of Scrum, according to the official Scrum guide - has grown to almost be a necessity. Most teams struggle to understand this, with Scrum masters complaining how challenging it is to do it properly. Scrumban makes it possible to avoid all this unnecessary confusion.

Project managers are used to handling ventures that have a definitive start and end date. They are often made up of cross-functional teams that might be together for 12 months or less. Teams like this can work well with Scrumban, through learning communication structures based on some of the Scrum ceremonies, with dedicated planning sessions to discuss project requirements.

Also, for many projects, specifically infrastructure ones, there will not always be a shippable product at the end of each sprint, which is one of the requirements of Scrum. Rather, teams would work continuously and move to production or another iteration when ready. Now, the Scrumban approach embraces an existing system or product lifecycle and simply adds to it the visibility of Kanban with some of the Scrum ceremonies.

What’s more, with Scrumban, project managers don’t have to forcibly find a single product owner to control the backlog. The role of a product owner is critical to Scrum, but in corporations, there are often multiple stakeholders with different kinds of requests, making it impossible for a single person to prioritize stories or issues. Scrumban does not call for standard-sized stories or a single backlog owner, but simply asks teams to ensure that the backlog is in clear view of all.

Transitioning from iterations to continuous delivery

Scrumban allows teams to shift from having to keep a set of determined planning times, to planning only when required. New to-do items might be discovered regularly in production. As opposed to Scrum, Scrumban does not force product teams to limit the sprint scope to 1-4 weeks, allowing production to take as long as is needed for the best results. While from a project perspective, this is where it ends, for most companies, this is just the start of the journey. Projects are carried about so that the temporary change initiated by them can continue to operate and realize benefits. Scrumban is very useful here.

Teams that have been using Scrum, may find it easiest to move towards Scrumban in the latter part of a project - when they transition from product development to maintenance and take on a continuous flow approach.

Now, what is the difference between Scrumban and Kanban?

Typically, teams using Scrumban boards will divide the workflow into more stages, than they would on a Kanban board. That is to show a more gradual nature of the process, stemming from the sprint-like approach to project planning. Very often, a Scrumban board still does incorporate a “sprint” stage or a “Stories” class of items. On those boards, it’s possible to track the progress of work related to a specific story or a specific sprint, regardless of the team working continuously.

Also, Scrumban teams are typically freer to prioritize items in columns, than people working with Kanban, which does tend to prescribe sticking to the FIFO rule.

Conclusion

As companies realize they need to move to a more Agile, Lean way of working, Scrumban is an easy way to go, with its removal of any unnecessary clutter from Scrum, that many a company will not need. It allows companies to continue to work in a way that is natural to them, but to - at the same time - implement the best Lean and Agile practices specific for continuous flow environments.

Scrumban can give you just the right amount of rigor you need, together with the flexibility, efficiency, and visibility of Kanban and Lean.

The key benefits of using Scrumban are:

• higher quality of completed work and just-in-time decision making
• increased speed of processing
• minimized waste
• more empowered teams, so happier teams
• continuously improved processes