TL;DR – Old Wine in New Bottles? 

Portfolio Kanban is more than a buzzword – it’s a powerful tool to bring transparency, flow, and focus to organisational project work beyond the team level. The post outlines how a simple physical board, regular standups, and iterative refinement helped a company gain clarity on what’s in progress, who’s blocked, and what really matters. Key takeaways:

• Visualise all initiatives, not just IT tasks, to reveal overload and misalignment.
• Create a shared forum (e.g., a 15-minute weekly standup) to track progress and surface blockers.
• Continuously adapt the system based on retrospectives and real use, focusing on value flow rather than status reporting. Done right, Portfolio Kanban becomes a conversation starter—reducing meetings, aligning priorities, and improving delivery reliability.

Starting with scenes from practice

What are we currently working on? – What do you mean? – Well, what are we as a company working on? – You mean which projects? – Exactly, on which projects and topics are the teams working? – By ‘working,’ do you mean what is in progress? – No, not only. Developing concepts is work too. – Well, technically yes, we used to have that on a board on a timeline. – Where is it and who maintains it? – Hmm, it was there in the front, no idea where it went…

A conversation with a colleague after my initial two weeks at the new company was quite similar. Despite numerous discussions, I struggled to grasp the overview of the projects being handled by the four teams in terms of sequence, duration, and status. Not to mention the respective priority for the company.

WIP Limits extended beyond the team level

When implementing agile methods in IT, we place significant emphasis on adhering to core practices such as Kanban (refer to: Kanban in IT by Klaus Leopold) – especially:

• Visualisation of the workflow
• Limiting work in progress (WIP)
• Managing and measuring workflow

If we grasp the agile principle correctly, we should also comprehend its fundamental purpose. It primarily focuses on economic aspects: creating the highest possible value in the shortest time for the company while avoiding waste. When implementing Scrum or Kanban, leaders often only consider the operational processes of IT teams to enhance productivity.

If IT were to develop faster, many problems would be solved, right? The organisation as a whole is not considered. It does not make sense to apply the flow principle only from the team and story level; it must be expanded further. What teams manage on a daily basis using artifacts like backlog and team board should also happen at the enterprise level:

• Establishing the pull principle and finding the right WIP limit: How many projects or initiatives can the organisation realistically handle?
• Flexible and continuous prioritisation: What comes next and why? Do priorities shift due to changing conditions or new insights?
• Identifying bottlenecks and dependencies: What resources are needed when—and are there external dependencies we need to resolve?

Even if the team is successfully adhering to the WIP limits – the number of tasks it works on simultaneously – we often encounter overload in the adjacent departments and their participants. Notably, the Product Owner, acting as the interface to the organisation, continuously has to deal with an excessive number of concepts, ideas, and requests concurrently. Consequently, it raises the question of why a Product Owner, unlike their team, cannot practically establish and maintain a WIP limit.

Initiating flow with Portfolio Kanban

Following my discussion with a colleague, I recalled a similar situation from my time as a Product Owner at a previous employer, prior to the establishment of the term Portfolio Kanban or Kanban in IT in general. The project portfolio was a jumble of requirements, bugs, and projects. Developers were continuously working on various topics simultaneously. Product managers were burdened with an ever-increasing load of requests and corresponding expectations.

“Prioritisation rounds for new projects occurred in overly lengthy cycles, turning them into true sales events.”

Tools for administration implied structure and transparency but often resulted in the opposite effect. The project roadmap for business units on an annual basis utilising Gantt charts was meant to ensure planning certainty and resource availability, yet typically quickly fell apart. Prioritisation rounds for new projects occurred in overly lengthy cycles, turning them into true sales events due to the One-Shot Effect.

The management team then implemented two changes: firstly, a weekly ‘Product Portfolio Council’ for prioritising and assessing the status of projects. Participants included the management team, the heads of the Business Units, a representative from the stakeholder teams, and the Product Owner. Secondly, a shift in the project planning approach from mere Gantt chart planning to a status review (Idea – Concept – In Progress – etc.). The impact was significant. Regular reviews and discussions brought out the previously perceived weaknesses in the product planning:

• Too many parallel initiatives and a tendency to want to do everything at once
• Long lead times for requirements, resulting in delayed value delivery
• Lack of a mechanism for continuously prioritizing new ideas
• Missing or poorly communicated product strategy—and, by implication, company strategy as well

Although there were still significant weaknesses in the measures (see last section), the transparency created led to a changed consciousness regarding which projects the company can and must undertake in what order.

Just give Portfolio Kanban a try

Returning to the initial situation. With this experience in mind, I proposed to the management to try Portfolio Kanban. There was also a shared belief that everyone should already know what is being worked on. Furthermore, there was a concern that introducing more ceremonies would increase the perceived meeting frequency. However, the counterargument that this approach would likely reduce the number of so-called regular meetings and save meeting time, along with the understanding that it is initially an experiment, persuaded them.

Portfolio Kanban – Step 1: Get out of your heads and onto the board

In the initial stage, I invited stakeholders, management, and product owners to a meeting to introduce the concept of a project or theme board. Beforehand, I had prepared a draft with a total of four columns for different statuses (Rough Concept, Detailed Concept, In Progress, Completed). Moderation cards, pens, and sticky dots for noting and marking were available, with a request to write all projects on cards and place them in the appropriate status. The resulting effects and discussions were very interesting:

• Even for some larger projects, senior management was surprised to learn that work had already begun…
• The size of the board wasn’t sufficient to cover the topics from all four IT teams. On average, each team had three to four cards just in the “In Progress” column…
• The definition of a “project” was unclear to many—especially the distinction between so-called “white noise” (bugs, mini-features, general background activity) and full-scale projects.
• One particularly interesting discussion revolved around whether we define a project solely as an IT initiative—or if purely organizational tasks, like planning the company Christmas party, also qualify.

The wish for a colour-coded system based on stakeholders was most perplexing. It highlighted a major flaw in the system: a parity principle aimed at maximum equality among all stakeholders. This implicitly placed the goals of individual departments above those of the entire company – or the company’s goals were unclear, shifting the focus to departmental objectives.

Portfolio Kanban – Step 2: Create a forum

I chose to accept the shortcomings initially. At least the first step, which was creating visibility, was taken. We agreed on a weekly stand-up with the same group, lasting a maximum of 15 minutes. It began with three questions:

• What has changed since last week?
• Where is there still a need for discussion?
• Are there any obstacles or blockers?

After the initial rounds, it became evident to all involved why the cards were moving across the board at a snail’s pace, if at all. One reason was the excessive number of topics being handled by the teams simultaneously. Additionally, the topics were too extensive in scope, making them difficult to manage. The question of what should be addressed next and why was answered differently by each member of the group.

One group had no information to provide. Others prioritised based on available IT capacity and specialisation. The third faction followed the parity principle, stating Stakeholder X (green colour) is currently underrepresented on the board and should be involved. Initially, moderating was challenging; the group was unfamiliar with independent board work, decision-making, and standup coordination.

Portfolio Kanban – Step 3: inspection and fine-tuning

Over the following weeks, the board and, in particular, the status labels underwent multiple adjustments. An additional status for post-assessment and analysis of new features and a column for blocked projects were introduced. The latter highlighted the number of issues that were ‘up in the air’ for various reasons, resulting in costs due to waiting (waste of time).

A retrospective on the project/theme board theme once again highlighted the principle of prioritisation. It became evident to most that the order of processing should be derived from the company’s goals (refer to 7 Steps to a Great Product Strategy). This information should be communicated more strongly by senior management to prevent silo thinking within the organisation.

Soon, the need for moderation during the weekly standups had noticeably decreased. The group independently managed the board, created cards for new projects and topics, and addressed additional discussion and planning needs. By marking the date whenever a new card landed on the board, recurring issues could be identified more effectively, and the average project lead time could be determined.

Blockades have been resolved, sometimes by the group’s choice to either kill or reevaluate projects due to high dependencies, complexity, or lack of relevance. The board was prominently displayed in a central location, and the stand-up was open to everyone, with at least one representative from stakeholders and teams expected to attend.

What has it achieved?

The core principle of Portfolio Kanban is not new but gains a different significance through the concept of flow. Visualising what, in what order, and for how long the organisation works allows for identifying weaknesses in the system and product planning. The perspective changes through examining the steps of work. Pure time-based planning using Gantt charts is becoming less important. The following effects, significantly influenced by Portfolio Kanban, were observed in the specific example:

• Smaller project or feature units – larger topics are broken down in time and made visible on the board for everyone
• This leads to shorter cycle times – also due to fewer parallel tasks per team and work step
• Fewer heavyweight alignment meetings – needs are more often identified directly in the weekly standup, and open points are discussed immediately afterward
• Greater planning reliability – thanks to improved visibility and regular communication in the standup about what is in which status, potential stakeholder dependencies and bottlenecks are identified earlier

What should be considered?

If we adhere to the fundamental principles and practices of Kanban, everything will go smoothly. However, the approach to implementing Portfolio Kanban needs to be tailored to the company’s context, such as the participants involved or the work stages and status labels. Key insights and practices include:

• Regular retrospectives: The focus here is not primarily on the design of the board or the process itself, but on the insights the group gains through Portfolio Kanban.
• Analog board: Just like with the teams, a physical board should be used here as well—for better tactile feedback and interaction. Exceptions prove the rule (e.g., distributed locations).
• Visibility: The board must always be clearly visible to everyone in the company. It defeats its purpose if the project portfolio is “hidden away” in the project management or even product management office.
• Regular standups: Once a week, 15 minutes max is usually enough. What matters is consistency and the right group of participants to keep the portfolio discussion alive.
• Separate project status tracking from decisions on new concepts and ideas: Deciding which concept or idea makes it onto the board requires a completely different setting—and possibly a different group of participants.

Portfolio Kanban is not an end in itself. Just like a User Story, but at a different level, it must be able to deliver on the promise of sparking a conversation.

Book Recommendation

Click, buy, and enrich me – my literature recommendation on the subject and an enlightening read on Kanban: All About Pull Production: Designing, Implementing, and Maintaining Kanban, CONWIP, and other Pull Systems in Lean Production

Hero Image: excerpt from the Portfolio Kanban board by Martin Heckmann