ScrumBan – agile for the indecisive or key to success?

Scrum and Kanban are probably the best-known agile frameworks. The 13th annual “State of Agile Report” shows: 58 percent of projects run according to Scrum, and in second place with 10 percent is a strange composite: ScrumBan. Kanban instead falls to fifth place with 7 percent. Reason enough to take a closer look at the meaning of ScrumBan. Is there a uniform procedure here or is every hybrid of Kanban and Scrum automatically ScrumBan?

Implementation of ScrumBan

So much in advance: The framework promises to combine the best of both worlds. ScrumBan is easiest to implement starting from Scrum, as a basic understanding of roles, events and artifacts is helpful. This is not a prerequisite, but you should know the basics of the Scrum Guide. The “Scrum” part gives the combined methodology more “grip” or agile practices than Kanban. The “Kanban” part directs the focus more on the process and the improvement of the workflow.

For which areas of application is ScrumBan particularly suitable?

ScrumBan is suitable for maintenance projects, possibly in combination with classic product development, event-driven work (helpdesk, support) as well as problem-oriented project management (with frequently unexpected user stories and / or bugs). In addition, Scrum teams can fall back on it before (backlog, R&D) and after sprint development (system testing, packaging).

But how exactly does ScrumBan work?

Here are six steps in which you can establish a working base:

1. visualize the work

Create a KanBan board with the essential work steps: “To Do, In Progress, Done” or adopt the columns you already use. Any work should be able to be recorded in a board. Choose the level of detail that is necessary for your team.

2. limit “Work in Progress” (WIP)

Teams – including Scrum teams – often have a weakness: various work is started, interrupted, and not taken up further for various reasons. This is waste. In Scrum, for example, this can manifest itself in the fact that all planned tasks have been started, but not all could be completed. Often this is also due to obstacles such as dependencies, absences, lack of knowledge at handover, etc.

The “WIP” limits the number of tasks per person or per column of the board. When the maximum is reached, the team cannot continue working without solving the blocker. This means that everyone on the team should participate in removing the blocker.

Studies show that it is therefore useful also in ScrumBan to move from “expert roles” to greater “T-shaped” knowledge per team member. The knowledge transfer required for this is therefore less time-consuming in the long run than the “lost time” when waiting for experts who can solve problems. The “WIP” limit ensures that the process is running and that any work that has been started – due to the process – can also be finished.

3. add buffer places and/or further columns

The “pull” principle known from Kanban is not lived holistically in Scrum: often work is “pushed” e.g. from the developer into the code review. Scrum cushions the problem with the idea of a self-organized team in which the skills are widely distributed. In reality, however, there are limited resources where the work would then pile up.

That’s why there are “buffer places” like “ready for code review”, where the developer can put his task after it is done. The next free reviewer then pulls those as soon as he has kappacities free. Also buffer places can be occupied with a “WIP” of e.g. two tasks. If these are occupied, it is a signal for the rest of the team to assist in code review. The flow is back on.

4. prioritize work

As in Scrum, work should be put into a sorted list. What is at the top is most important. Alternatively, you can work with prioritization levels (critical, high, middle, low or similar). This ensures that the most important is worked on first. Who prioritizes? In Kanban this is not defined, in ScrumBan the Product Owner has the last word. If you haven’t worked with the roles before – introduce them now.

5. measure flow, but leave out estimates

From Kanban comes the focus on flow, which can be measured e.g. via lead times. How long does a task take through the workflow (e.g. from To Do to Done?). Tools like Jira can support you there and generate a “velocity” over time similar to Scrum.

However, we don’t need estimates like in Scrum, because we don’t plan iterations (sprints). Estimates have an advantage, though: In the conversation why the task is estimated larger or smaller, a valuable discussion usually results on how the implementation can look like. This can also be stimulated in the ScrumBan, even without an estimate as a result.

6. Trigger Refinements

Refinements do not always have to be linked to fixed iteration cycles. ScrumBan says: Set a trigger for your tasks to be done (ideally column “Ready for implementation”). When the number of tasks falls below a certain number (e.g. 5), a trigger is fired: time for refinement. Only then are new tasks created or made ready for implementation.

Considering these six steps, a ScrumBan in a project could look like the following:

Keeping an eye on the continuous improvement process

In addition to refinement, it is also advisable to keep an eye on the continuous improvement process: For this, the retrospective has proven itself as an event in Scrum. So that the daily synchronization of teams of from Scrum proven 3-9 team members does not come too short, it is also recommended to introduce a Daily. Thus we come to the following min. recommended ScrumBan events:

• Refinement (irregular – see Trigger)
• Daily
• Retrospective

Trigger acceptance of tasks

A review in the sense of an acceptance of tasks can also be triggered: All tasks in a certain status are then reviewed and accepted by the PO. For this purpose, the “Done” status or a “Ready for Review” status can be used (be careful with the terminology to distinguish the code review from this). If there is a need for clarification with the team, this can be organized ad hoc – the same principle applies as for refinement.

Conclusion

ScrumBan promises – correctly used and applied – high quality, just-in-time decisions, short lead times and minimal waste of resources (everything that is started is also implemented).

As always, no matter what methodology, there is no ONE key to success for all projects. However, if you are currently struggling with a high number of unplanned work or a lot of started but little completed tasks, it is worth trying ScrumBan as a framework.