Portfolio Kanban
Portfolio Kanban is a board that places each strategic initiative of a portfolio in the column of the milestone it has reached, from the idea through to delivery into use. Each column carries two written rules: the criterion that lets an item leave it and the maximum number of items admitted at the same time. A refinement meeting brings the decision-makers and the owners of the initiatives concerned together at a regular interval to review the board, examine the columns where work is piling up and reprioritise. The technique applies to a portfolio the practices of the Kanban method, formalised by David J. Anderson for knowledge work; the Agile Extension to the BABOK Guide places it at the Strategy horizon.
Goal
Portfolio Kanban shows a portfolio committee where all of its initiatives stand at the same moment: one card per initiative, one column per stage of the path the organisation makes them follow. The Agile Extension gives it the purpose of managing the implementation of strategic initiatives; the means is visibility, over the process, over the work in progress, over the decision criteria and over the feedback loops. Work in progress, which the tools call WIP, is the number of items under way at a given moment.
The problem it addresses is the portfolio trade-off made on a list. A tracking spreadsheet carries the rank, the budget and a percentage of completion declared by the project manager, three pieces of information that say neither how many initiatives are open at the same time nor how long any one of them has been standing still.
The deliverable is the board itself and its set of written rules. Two of them do the work: the exit criterion of each column, which replaces case-by-case judgement of what counts as "done", and the limit on work in progress, which forces work to be finished before more is started. The guide places the technique at the Strategy horizon, the widest of the Agile Extension's three horizons. It notes that it replicates at the Initiative and Delivery horizons.
Usage
When to use it
- Initiatives that follow the same milestones: a common set of columns becomes possible, which is the condition of the technique.
- A committee that starts more initiatives than it finishes: the limit per column demands an exit before each entry.
- A bottleneck suspected without proof: the column where the cards pile up names it, with figures.
When not to use it
- Initiatives with different paths: no common set of columns, so keep one board per flow or decide through prioritisation.
- A single queue feeding one team: backlog management answers the same question for less.
Description
Six practices taken up to portfolio scale
The six points of attention in §7.9.3 of the Agile Extension are the six general practices of the Kanban method, transposed to the portfolio. The method descends from the shop-floor kanban pull system; David J. Anderson transposed it to knowledge work in 2010. The SAFe framework carries the technique under the same name: there the board moves epics from ideation through analysis and on to implementation.
| Practice of the Kanban method | Its shape on a portfolio |
|---|---|
| Visualise the work | One card per initiative, one column per milestone. The board shows everything that is under way, including what nobody mentions any more. |
| Limit work in progress | A numbered limit per column, set on the capacity of those who work in it. |
| Manage flow | Spot the bottlenecks and the stalled initiatives, then act on the column that is blocking. |
| Make policies explicit | A written exit criterion per column and the criteria on which funding is decided. |
| Implement feedback loops | The refinement meeting at a fixed cadence and the impact metrics reported initiative by initiative. |
| Improve collaboratively | Columns and limits are revised when the flow observed contradicts them. |
The elements of the board
The columns take up the stages an organisation already makes an initiative go through, from the idea to value made available. They are read off the last initiatives carried to completion, including the passages nobody calls a milestone: a security review, a legal opinion, a budget approval outside the cycle. The example board the Agile Extension gives, running from the waiting queue to the available product by way of the market study, the minimum viable product and the security review, describes the milestones of one particular organisation.
The exit criterion of each column says what has to be established for an item to move to the next one. It is written as one sentence that someone who has not worked on the file can verify: for a regulatory review, the written opinion of compliance, with or without conditions.
The limit per column is the maximum number of items admitted at the same time. It is set on the capacity the department has demonstrated over the past year. Once reached, it bars entry until something leaves, which shifts the committee's work towards unblocking what is already under way.
The portfolio item carries a name, a short description and the impact metrics or objectives that will serve to prioritise it and then to measure its contribution to the organisation's objectives. The impact metric is what makes two unrelated initiatives comparable. Two fields the guide does not ask for make the board workable in the meeting: the date of entry into the current column and the amount committed to date.
The refinement meeting brings together at a regular cadence the decision-makers and the people their decisions affect, including the owner of each initiative. The guide gives it no format; it describes its products, namely the review of the board, the analysis of the areas that call for attention and the reprioritisation of the existing items. This is the technique's feedback loop: without it, the board becomes a display nobody argues with any more. Backlog refinement is the same practice at the scale of a delivery team.
Visibility is an element in its own right. The board is open to anyone who wants to look at it, and the guide gives the advantage to physical representations. A digital board behind an access right requested from the IT department loses the visibility that makes the technique.
The order of setting up matters: list the initiatives under way, read the columns off past initiatives, write the exit criteria, place the cards and only then set the limits on the distribution observed.
The portfolio board and the backlog
Both techniques order work still to come; the resemblance stops there. Backlog management keeps a single list ordered on one dimension, the rank, which a team draws from as its capacity frees up. The portfolio board spreads initiatives across explicit stages, each with its passage criterion and its limit, at the pace of a periodic meeting of decision-makers.
A backlog says what the team takes next; a portfolio board says where each initiative has stopped and which stage is saturated. An organisation commonly uses both, at two different levels: the board at the Strategy horizon, the backlog inside each delivery team.
What makes the technique fail
The limit that gets raised
A limit has an effect only at the moment it gets in the way. A committee that raises it from three to four to let an urgent file in, then to five the month after, has kept the board and removed the technique. A limit is revised on an observed trend in the flow, outside the meeting where an item is trying to get in.
The card that does not move
The guide states this limitation itself: the technique stops bringing clarity when an item stays a long time in the same column. The board goes on displaying an accurate situation, and the committee gets used to seeing it. Dating each card's entry into its column turns standing still into a figure that grows at every meeting, and the initiative is cut into items that cross milestones on a quarterly scale, around a Minimum Viable Product (MVP) for instance.
The board updated after the decision
The committee decides in a meeting, someone moves the cards the next day. The board becomes a record of proceedings, a function the minutes fill at lower cost, and it loses the one that justifies its existence: showing, at the moment of the decision, that the target column is full.
Two flows on one board
The guide confines the technique to a single flow system. Putting the strategic initiatives and the change requests on the core system on the same board mixes two populations whose milestones and durations have nothing in common, and the committee spends the meeting on the change requests, more numerous and quicker. Two boards, two sets of columns, two limits.
AI considerations
A language model serves this technique between meetings. From a history export, it computes the time each card has spent in each column and flags those that exceed the usual duration of their stage, which prepares the agenda of the refinement. It also harmonises the wording of the exit criteria, often written by five departments in five styles, and picks out two initiatives declaring the same impact metric, a frequent sign of a duplicate or of a badly cut scope. On an initiative description, it proposes candidate impact metrics, useful as a starting point when the field is left empty.
A column limit is not something to ask a model for. It expresses a department's capacity to process files, known to those who sit in it, and a model ordered to set it will produce a plausible number with no origin. The order of the initiatives is decided the same way: it depends on commitments made, on balances of power and on constraints the board does not carry. A stalled card often has a political cause, a regulator waiting for an answer or an internal opponent, invisible in the dates. A portfolio board carries committed amounts, unannounced market entries and supplier names: these are stripped out before anything goes to a public model.
Examples
A health insurer in French-speaking Switzerland, around 550 staff, holds six initiatives under way and two requests submitted since the last meeting on a board its portfolio committee reviews every month.
The limit sits on the funding-case column, set at three because the committee processed three cases per monthly meeting over the past year; it is reached. The core-system replacement, committed to the tune of CHF 4'200'000, has occupied the regulatory review column for two cycles, where the other initiatives pass through in one.
| Column | Exit criterion | Limit |
|---|---|---|
| Ideas submitted | A one-page note naming the expected benefit and the person carrying it. | none |
| Funding case | Costed multi-year budget and funding decision by the committee. | 3 |
| Build | Solution signed off by the acceptance tests of the business areas concerned. | 4 |
| Regulatory review | Written opinion of compliance, FOPH for basic insurance, FINMA for supplementary cover. | 2 |
| In service | Solution in production and first impact measurement taken. | none |
The meeting had been called to decide between the two submitted requests, entry into a supplementary insurance line and the migration to ICD-11; the full funding column leaves that decision without an object until a case comes out of it. The month's decision therefore bears on the regulatory review, where two cycles of delay are freezing the largest amount in the portfolio: the committee charges compliance and the supplier with a processing schedule within fifteen days, and the two requests stay in the Ideas submitted column until the next meeting. A tracking spreadsheet would have displayed the eight rows, their budgets and their percentages of completion, without making either the saturation or the wait visible.
Visualisations
The board is drawn as columns laid out in the order of the flow, one card per item, the limit shown at the head of the columns that carry one, beside the number of cards standing in them. The card carries its date of entry into the column, which makes the wait readable without arithmetic. A return arrow runs from the refinement meeting back to the entry of the board, the loop by which reprioritisation comes back onto the flow. What has to be seen at a glance is the full column and the card that has not moved.
The set of written rules reads as a table, one row per column. It is the document the technique produces beside the wall and the one that is most often missing.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | Listing the initiatives takes half a day. Agreeing the columns and writing the exit criteria call for several exchanges with the departments that pronounce the passages. |
| Execution | Low | A refinement meeting of one to two hours a month, with participants already brought together elsewhere, plus moving the cards. |
| Documentation | Medium | The board is its own document. The spending goes on the impact metrics, which have to be gathered initiative by initiative for prioritisation to rest on figures. |
Tooling
The guide gives the preference to the physical board: a wall, columns marked out in adhesive tape, one card per initiative. It is handled standing during the meeting and stays in view between two committees. It assumes a committee that meets in the same place.
The flow management tools (Jira, Azure DevOps Boards, Businessmap, Trello and their equivalents) refuse the card that would take a column past its limit and keep the history from which the durations per stage are derived. The risk lies in their default columns, which invite an organisation to borrow another one's path.
The collaborative whiteboards (Miro, Mural and their equivalents) suit a committee spread over several sites. They reproduce the surface and the handling, provided someone shares the screen during the decision.
Most portfolios are held in a spreadsheet. It carries the items, the budgets and the metrics. Neither the limit nor the flow finds a place there: nothing stops anyone adding a row. It stays useful beside the board, for the committed amounts and the history of decisions.
There remains the tool prioritisation depends on: the system that produces the impact metrics, a decision-support dashboard or an operational report. An impact objective nobody knows how to measure each quarter turns the card into an intention.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.9 Portfolio Kanban: the purpose of the technique, the six points of attention of the flow system, the elements of the board, the strengths stated, among them replication at the Initiative and Delivery horizons, the three limitations and the placement at the Strategy horizon.
- David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010: the formalisation of the Kanban method for knowledge work, whose practices the technique transposes to the portfolio.
- Kanban University, The Official Guide to The Kanban Method: the common statement of the six general practices of the Kanban method, the ones the figure transposes to a portfolio.
- Scaled Agile Framework, Portfolio Kanban: the definition of the technique at portfolio scale, as a system for visualising and managing the flow of epics, from ideation through analysis and on to implementation.