What are the pitfalls in using Scrum and Kanban boards at the same time (different purposes)?

[Ben Parry]

Hi - hope this isn't too strange a question. I have two differing requirements - I need to schedule work ( and make outline promises on delivery dates) whilst being able to show predictable,improving delivery. 

I'm keen on using a Scrum board to plan 2 week runs of work (that's the only 'contract' that really works for Project Managers across Waterfall & Agile projects).

The  Kanban board would have  'done' queues after each status. There are multiple hand-offs in my process so I want to measure wait time at each. Knowledge of a constraint would inform capacity for future Sprints. If there's growing WIP and a bottleneck, it would be good to be able to set expectations that less new work could be added to the next Sprint. Alternatively if pace is picking up and cycle time is improving I could talk more optimistically about future delivery.

I hope I'm not confusing the two approaches and not trying to 'have my cake and eat it'. Have I overlooked any obvious pifalls? Has anybody else tried this?

[Nic Brough -Adaptavist-]

It's something I suggest to people a lot actually.  Use one scrum board as a scrum board, and then one or many Kanban boards to visualise and amend your data for other processes. 

One good example for me was a design company that did kanban/scrum/scrum/kanban.  The first kanban covered new stories and a design phase, where timings were not structure-able into sprints.  Then the developers did a 2 week sprint on the first scrum, the testers doing another 2 week sprint (offset by a week) and anything that passed testing went into a delivery phase where everyone one is juggling things like delivery team and client availability.  You'll note there that the boards do not map all status in the flow.  Each board only covers part of the workflow, with the "to do" column on boards 2-4 being the "done" columns on boards 1-3.  There's then more kanban boards giving people overall views and views of part of the process

The pitfalls:

• Minimise the number of scrum boards, especially if they share more than one column, it can get confusing for users.
• Be very very careful with kanban "release" options, setting the version could upset things on other boards.
• Make sure all your users know you are doing this, even if they only need to use one board.
• Be absolutely clear that the boards are not containers for issues, they are a view.  So changing something on one board affects the issue, and hence is shown in other boards.

[Ben Parry]

Thanks Nic! I'm reassured this is worth pursuing.