I was wondering when a small development team would use kanban when they have multiple simultaneous IT projects.

Is there a reason why someone would rather go with kanban instead of Scrum when managing multiple projects?

My guess is that they will have a separate work board per project and define on a different board which tasks they will complete in this given timespan.

  • related question: pm.stackexchange.com/q/12709/4271
    – Todd A. Jacobs
    Commented Nov 30, 2014 at 16:29
  • 1
    Scrum and Kanban are not exclusive to each other; they sit nicely within the same workspace and most Scrum Boards are actually just Kanban developed to aid Scrum. Commented Dec 10, 2014 at 18:02

4 Answers 4


The key phrases to remember with Kanban are 'visualise the backlog' and 'limit work in progress'. For this reason I think Kanban is best managed using a single board. Otherwise people find it hard to visualise the total amount of work that needs to be done or that is currently in progress. Multiple boards also make it harder to set hard limits on the total number of tasks that the team can have in progress at any given time because you'll need to count up the total across several boards to keep track.

To manage multiple projects (or even themes within a single project) I use swimlanes to visually split the work out but keep it on the same board e.g:

|           | To do       | In progress | Done |
| Urgent    | T-69        |             | T-6  |
| Project 1 | T-103 T-204 |             | T1   |
| Project 2 | T-30        | T-97        | T-12 |
| Project 3 | T-465 T-500 | T-34        |      |

That way you can set per column limits for total workload rather than per project, and you can get an instant visual representation of the total number of tasks in each status.

This can, of course, become quite unwieldy, especially if you're using a physical board. I use JIRA Agile to manage the process, using Quick Filters pretty heavily to quickly switch between views of the work.


Our team personally use different coloured cards to ally each user story to a particular project.

Each Project is treated as an Epic with it's own requirements documentation and a it's own timeline.

  • Is there a reason why someone would rather go with kanban instead of Scrum when managing multiple projects. -- you didn't answer the question. I am assuming that's why you got the down vote. You didn't get the down vote from me.
    – Ominus
    Commented Apr 13, 2017 at 21:20

From personal experience I can tell that teams starting with Kanban on multi-project environment has a way faster and higher success rate. Firstly, because Kanban is visual, secondly then Kanban has a very flexible structure that can be mapped out on the eletronic or physical whiteboard, separating Kanban Board into areas that represent individual projects.

Second important aspect is that Kanban systems usually employ swimlanes, which can be used as project tracks and boundary markers. WIP limits can play a nice limiter role cutting across all the projects.

My opinion does not mean that scrum is not good in this case, mature IT teams can leverage a lot of value by using scrum methodically, but that is costly and takes time as well as strong culture.

An example of Kanban system used for multiple projects: enter image description here

Image credits: https://teamhood.com/kanban


Kanban and Scrum is not comparable but think about this: Scrum is for one project in an iterative fashion. You have more than one project, possibly in a continuous fashion, so you are better of with Kanban. Nevertheless, have every second week a retrospective to see how you are doing and what you can do better.

  • Scrum and Kanban are comparable. In actual fact the Scrum Alliance compares them directly. The truth is, which most Scrum purists hate, is that Scrum and Kanban sit happily next to each other in most Agile departments or teams. Scrum would be harder to manage without a Kanban Board. It is why all Scrum software includes Kanban Boarding. scrumalliance.org/community/articles/2014/july/scrum-vs-kanban Commented Dec 4, 2014 at 7:55
  • Look, scrum is a software development process, Kanban is a management method. The reason why they can work together is that Kanban needs an underlying process. Therefore, you cannot compare two components that have dependencies (and you don't have to compare them, really). Moreover, the scrum board has nothing to do with the Kanban board. Finally, the author has no Kanban experience, therefore it is hard to take her article as it is.
    – Zsolt
    Commented Dec 4, 2014 at 20:53
  • Scrum is a software development process? We better inform the Scrum Alliance - scrumalliance.org/resource_download/548 I fundamentally disagree that Kanban needs an underlying process - it does not. It works perfectly fine on it's own. The Scrum Board is, at it's heart, a Kanban Board utilizing Ready, WIP and Done. The only real difference is that a Scrum Board is reset between between Sprints and Kanban is not. You are trying to pigeon hole processes and deny their similarities. Commented Dec 5, 2014 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.