A portfolio Kanban is a visual, simple tool that provides your organisation with an overview of all projects that are in the pipeline. It tells you what is waiting to start, what is in the planning stage, what is currently being developed and what has been completed. Or something along that line, depending on what you are interested in to know about your projects.
The structure of your pipeline
Don’t be surprised if it takes you a while to find the perfect format of Portfolio Kanban for your organisation. You will find that your Kanban might change a lot over the first months as you get to learn which stages of your project are important to understand and monitor. I tend to start with the most basic stages:
- Ready to start
Each of these stages ends up being a column on your Kanban wall. You can use a physical wall using post it notes or cards, or a digital Kanban such as Trello. Every project that is in your team’s pipeline ends up on an individual card and is moved through the Kanban as it progresses through the various stages.
Once you have started with the default structure, you will soon find that you want to rename your columns, that you need to add more stages or remove others. This is natural as you will most likely want your Kanban wall to reflect your organisation’s project governance or workflows. If there are stages for approval that a project needs to go through before it is allowed to commence, add those. This way you will always know what is blocking a project from proceeding, where it spends most of its time and you will ensure that every project goes through the steps it is supposed to go. You may end up with a structure such as this:
- Ready to go
Detail about the project
When you work with a Kanban wall for a project, as opposed to a wall for an entire portfolio, a single post-it note is often sufficient to display information about a given task. However, when you try to provide information about an entire project you might find that a post-it just does not do the trick. You will want to provide more information that just the title of your project. For a recent client we printed out A5 templates onto paper, stuck them with blue tack onto the wall and included for each project:
- A short description
- Photos/names of the key contributors
- Photo/name of the Product Owner
- Photo/name of the Senior Responsible Officer
Controlling work in progress
If you have clearly defined, static teams in your organisation that a project is being assigned to (e.g. Developer Team A, Developer Team B) then you may wish to add streams (rows) to your Kanban. This way you know which team is busy with which project(s) and you can start controlling the amount of work using WIP Limits. The Scaled Agile Framework (SAFe) provides suggestions which stages of your Kanban might require WIP Limits.
However, if you work with an organisation that creates and dismisses teams as projects come and go, and the amount of work the organisation is willing to spend on projects changes from one moment to another, then you cannot use WIP Limits to control throughput. This is a lot more difficult to control, but it is a common occurrence in organisations that have a strong mix between Business-As-Usual (BAU) and project teams. Sometimes you may have 5 people available to work on projects, other times you have 20. In these cases you will most likely not introduce streams or WIP Limits to your Portfolio Kanban, but instead you will have to make a judgement call on how many projects are realistic. It might take a few cycles of projects before you are experienced enough to estimate realistic throughput, but it will come eventually.