by Christine Thompson
Why ScrumBan?
I first started looking into ScrumBan when I was working with a team who had been doing a prolonged period of feature development and had a well-established Scrum process. Everything was working well for us until we started to transition into a phase of bug fixing and support. Suddenly we found that we had too much support to have predictable sprints. We could never finish a sprint because the support tasks couldn’t be sized accurately. Our priorities were constantly changing, as new issues came in, and we couldn’t lock-down the sprint. Things went into and out of the sprint and our burn-down started to look like an electrocardiogram.
I started to question then whether we should be looking at a continuous workflow and moving over to Kanban. This way we would be able to respond quickly to priority changes, limit our work in progress and work on tasks that would take more than sprint. But Scrum had worked so well for us that I was reluctant to move away from it completely. This is when I hit on ScrumBan.
What is ScrumBan?
ScrumBan combines the framework of Scrum with the principles of Kanban. It is more prescriptive than Kanban, which has no roles or meetings, but is more responsive to change than Scrum, where change can only be accommodated at the sprint boundary. ScrumBan retains all the roles and meetings of Scrum but uses the Kanban continuous workflow board. The daily stand-up focusses on flow of tasks across the board and reviews what it would take to move each one forward. The workflow can even include both support and feature work items on the same board, for teams who have to progress tasks in both areas at once. This is a neat solution to dividing teams in half, where those who end up in the support team are generally less impressed than those who remain on the feature team! It allows people to vary the type of task they pick up each time and to share the support load.
Using the Kanban board allowed us to take advantage of some of the lean principles of limiting work in progress and eliminating blockers. We had a limited number of “Ready” slots available on the board, which the product owner would fill with the top priority items. Should priorities change, or new requests come in, these could be swapped in and swapped out as needed. Ready to progress items were ordered in priority and the team was asked to try to progress the top items first, wherever possible. This was a real exercise in team empowerment and collaboration, and people worked hard to pick up priority items first, rather than those which just looked the nicest! As the Scrum Master, my role remained to facilitate this process and assist to eliminate the blockers that arose.
ScrumBan activities
We kept many of the Scrum ceremonies in place, relatively unchanged. The daily stand-up reviewed the progress on the board and allowed individuals to exchange information and offer assistance, even though they weren’t interdependent from working on shared user stories. The stand-up also allowed the opportunity to review our work-in-progress so ensure that individuals weren’t progressing too many tasks in parallel and that nothing was blocked. We retained a weekly backlog sizing meeting to review the new tasks in the backlog. The sizing exercise was still of value in allowing conversations to be held and shared understanding to be reached on what the tasks entailed, even though we weren’t tracking our velocity as before. The Product Owner maintained a backlog of around 10 items in the to-do list at any time, pulling in more from the backlog as soon as the list ran low. As new, high priority items came in, the Product Owner would add these to the top of the to-do list, removing lower priority items back onto the backlog, as necessary. The Product Owner was also always on hand to answer questions about the requirements around the issues that were being addressed and the test coverage necessary to extend our regression suite. In our case, we didn’t hold a sprint review-type meeting, because the increments were limited to bug fixes. However, I see no reason why there shouldn’t be value in this type of meeting, for sharing the solutions that had been implemented. And, of course, retrospectives were as valuable as ever in reviewing our process and making improvements as the team felt necessary.
Final thoughts
The advantage of moving from Scrum to Scrumban, rather than pure Kanban, is the retention of much of the Scrum framework. For a team that needs to move from feature work, to support & bug fixing and back again, this provides a less onerous transition as many of the meetings and the general heartbeat of the team remain unchanged. Further, even for teams who only ever do support, I still see a great deal of value in having the Scrum roles and ceremonies in place as I believe that these add a lot of value which could be missed in a pure Kanban environment.
