The Problem Shows Up the Moment a Second Team Adopts Kanban
Kanban solves a real problem for a single team: work is visible, work-in-progress is limited, and everyone can see what is stuck without a status meeting. Most teams that adopt it stay with it, because it is hard to go back to a spreadsheet or an inbox once a board exists.
The trouble starts once a second team wants the same thing. Then a third. Each team's board is still perfectly legible on its own, but nobody above team level can answer a simple question anymore: what is actually moving across the organisation this month, and where is it stuck? Ten well-run boards do not add up to one clear picture — they add up to ten tabs open in ten different places, each telling a true but partial story.
This is not a Kanban problem specifically. Jira has the same shape of issue once an organisation has more projects than any one person can hold in their head, and Asana and monday.com hit it from the other direction, with dashboards that summarise activity but rarely summarise flow. The pattern is general: tools built to make one team's work visible were not built to make many teams' work comparable.
What "Portfolio Kanban" Is Actually For
The fix that has emerged over the last decade goes by a few names — portfolio Kanban, flow management, cross-team flow — but the idea is the same in each case: keep every team's board as the thing people actually work from day to day, and add a layer above it that rolls the boards up into one view without forcing every team onto identical columns.
Done well, that layer answers three questions a stack of individual boards cannot: where is work piling up across the organisation, not just on one board; how long does work actually take from request to done, measured the same way everywhere; and which initiatives are actually moving this quarter, as opposed to which teams are merely busy.
Done badly, it becomes another dashboard nobody trusts, built on data entered inconsistently by teams who were never asked whether the extra fields were worth the friction.
The tools that succeed here tend to share three traits: automation that keeps the roll-up accurate without manual re-entry, permissions granular enough that a department head sees their slice without wading through everyone else's, and an underlying model flexible enough that a design team's board and a platform team's board can both feed the same portfolio view without either one being forced into the other's shape.
One Example: Businessmap's Take on the Same Problem
Businessmap — renamed from Kanbanize, and built by Businessmap Ltd. in Dimitrovgrad, Bulgaria — is one of the tools built specifically for this layer rather than for the single-team board underneath it.
Its pitch is portfolio Kanban across multiple teams at once, with workflow automation rules that move cards without someone manually updating status, and governance features (SSO add-ons, dedicated cloud instances, unlimited API calls on its Enterprise plan) that only start to matter once more than one department is on the platform.
The company structures pricing around two tiers, Standard and Enterprise, both billed per user per month without a published rate card — annual billing brings the cost down by more than 20% against paying monthly, and a free trial gives full feature access on real data rather than a sandboxed demo.
Worth knowing before evaluating it: Businessmap's default data centre is in the United States, with an EU region in Ireland available if you ask for it rather than by default.
The contracting entity is Bulgarian either way, and its terms of use state that Bulgarian law governs the contract, but teams for whom EU-default hosting is a hard requirement should raise the Ireland option explicitly during procurement rather than assume it.
None of that makes it the right choice for every team outgrowing a single board — it is built for organisations that already have several teams and a real reporting need above them, and it is heavier than a small team migrating off one Jira project alone is likely to want.
For that narrower case, the honest advice is to look at what your existing tool's own roadmap and reporting views can already do before adding a second platform on top.
What to Check Before Buying Into This Layer
Whichever portfolio-level tool is under consideration, the same handful of questions decide whether it earns its keep a year in:
- Does it read from existing boards, or does it require re-entering data? A portfolio layer that needs manual updates on top of team-level boards will be abandoned within a quarter.
- Where does the data actually sit, and is that the default or something you have to request? The answer is not always what the marketing page implies — ask directly and get it in writing.
- Can a department head see only their own slice? A portfolio view that exposes every team's numbers to every other team creates its own political problems.
- What happens to the price as headcount grows? Per-user pricing that looked reasonable at fifty people can look very different at two hundred.
The underlying shift is a real one: as engineering organisations grow past a handful of teams, the tooling question stops being "which board is nicest to use" and becomes "which layer tells the truth about where work across the whole organisation actually stands." That is a different product category from the one most teams start with, and it is worth evaluating as one.
