Scrumban is the happy marriage of Scrum and Kanban Agile methodologies. It sprang up with the need to cater to changing priorities of clients while maintaining the frequency of quality production releases.
For the uninitiated, here’s a synopsis of what Scrum and Kanban is:
Scrum is the Agile methodology that encourages faster delivery of self organizing, cross functional teams through regular development cycles called as Sprints(usually 1-4weeks). Each Sprint begins with a Sprint Planning session in which the team commits to some work. The team then works throughout the duration of the Sprint, meeting everyday for a short catchup(Standup). At the end of the Sprint, the team showcases the work to the client(Demo) and requests feedback. This feedback is incorporated and the work is release to the Production. The team then meets at the end of the release cycle(Retrospectives) to understand what and how could they improve to deliver better next Sprint. This is most suited for the development projects that have a steady work flow and fair clarity on the work ahead.
Kanban is pull based Agile methodology with its roots in manufacturing industry that encourages continuous flow of work by optimally limiting the work in progress(WIP). It is more free-flow method as compared to Scrum and does not abide by any ceremonies. The team works on the most important tickets at all times and does not take on any additional work unless the current work is done. This works beautifully for the production support teams that have ever changing backlog depending on the tickets reported.
Scrumban is where the team works on the most important and highest priority work at all times, but still goes through Just in time planning/review cycles. Most Scrumban teams still follow the key Scrum ceremonies like Sprint Demo/Standup/Retro. They may have Sprint Planning Sessions too but are more flexible in changing the scope of work within the development cycle.
So Scrumban as the name suggests = SCRUM + Kanban. This style of Agile methodology is my personal favorite as it allows to work on dwindling priorities and still lets you take advantage of the structure that Scrum provides. This not only makes the team high performing but also avoids the hassles of cancelling Sprints midway due to change in priorities.