Work-in-progress limits in a portfolio are caps on how many initiatives may be active at one time, set against real capacity rather than ambition. They are the mechanism behind "what we are not starting," and they are the difference between a ranked list and a ranked list anyone follows. Portfolio WIP limits are set in the Align practice, before planning, because a limit agreed after the work has started is a cancellation conversation rather than a limit.
How do portfolio WIP limits work?
A portfolio limit says that no more than N initiatives may be in the active state at once, where active means consuming people. Rank the candidates, draw the line at N, and everything below the line is sequenced rather than started. When an initiative finishes, the next one crosses the line. That is the whole mechanism, and its difficulty is entirely social.
What it fixes is an arithmetic problem that gets treated as a motivation problem. When an organization commits more parallel work than it has people to finish, every initiative gets a fraction of the specialists it needs, each one moves slowly, and none of them finish cleanly. The usual response is to ask for better focus, more detailed status reporting, or a new tool, none of which change the arithmetic. Limiting the number of active initiatives does.
The effect shows up in three places. Work finishes sooner, because capacity is concentrated rather than spread. Status becomes simpler, because there are fewer things to report on and each has real people on it. And the portfolio starts producing explicit deferrals, which is uncomfortable at first and is the signal that the limit is real.
What does a good portfolio WIP limit look like?
A good limit starts from what is actually active, including work nobody approved, and it is usually set by a few scarce skills rather than overall headcount. It is close enough to the current state to survive day one, because a limit that requires stopping half the portfolio at once will be overruled. Everyone agrees what "active" means, the right to exceed the limit belongs to a named person under your decision rights, and the active set is protected for the length of the stability window. What is not being started is published with its rank, because a limit without a visible queue reads as a refusal instead of a sequence.
The sign it has become real is that something already running gets paused on purpose. The first time an organization stops its lowest-ranked initiative and moves those people to the top-ranked one is usually the first time anyone believes the ranking.
What does a portfolio WIP limit look like in practice?
Say a PMO with six delivery teams has 23 initiatives marked in progress. Nobody set that number; it accumulated. A count of who is actually assigned shows that four of the teams are split across five or more initiatives each, and that two integration engineers appear on nine.
The limit is set at eight active initiatives, with a sub-limit of two per team and a hard rule that the two integration engineers appear on no more than three initiatives between them. Fifteen initiatives move to a ranked sequence behind the line, each with the decision point at which it will be reconsidered.
Three things tend to follow. Some of the fifteen turn out to have no sponsor willing to defend their rank, and they leave the portfolio entirely, which recovers capacity nobody had accounted for. The active initiatives move faster than comparable work had been moving, because the people on them are no longer being pulled elsewhere. And the first urgent request after the limit is set gets a real answer: it can start when something finishes, or it can displace a named initiative, and the sponsor of that initiative is in the room for the conversation.
What happens when the portfolio is at its limit?
The answer has to be decided before the situation arises, or it defaults to "add it anyway." Three legitimate responses:
- Queue it. The request is ranked and waits for the next decision point. This is the default, and it requires that the queue is visible and dated.
- Displace something. The request enters and a named initiative is paused, with its capacity explicitly released. Displacement is a decision with an owner and a record, not an adjustment.
- Raise the limit. Legitimate only when capacity genuinely increased, for example when a team was added. Raising the limit because the queue is long is how the limit stops meaning anything.
What is not on the list is a very common real-world response: accepting the work and asking teams to absorb it. That converts a portfolio problem into a team problem, and the team's own limits absorb the damage.
What are the common mistakes?
Counting projects instead of capacity draw. Eight small changes and eight platform replacements are not the same load. If your initiatives vary wildly in size, limit against the constrained roles rather than the item count.
Ignoring unapproved work. A limit applied only to the official list leaves the shadow portfolio untouched, and the shadow portfolio is usually where the scarce specialists are spending their week.
Setting the limit at the aspiration. A limit chosen because it sounds disciplined, with no path from the current state, gets exceeded immediately and then ignored permanently.
Leaving teams to hold the line alone. Team-level limits erode when the portfolio above them keeps starting work. The limits have to exist at both levels, and the portfolio one comes first.
No visible queue. Without a published sequence, a limit looks like obstruction. With one, it looks like a plan, because every deferred sponsor can see their position and the date it changes.
Portfolio WIP limits vs team WIP limits
They are the same idea applied at different altitudes, and they fail without each other. A team WIP limit caps how many items are in a column on a board, and it governs flow inside work that has already been chosen. A portfolio WIP limit caps how many initiatives are chosen at all, and it governs what reaches the team in the first place.
| Portfolio WIP limit | Team WIP limit | |
|---|---|---|
| Unit | Initiatives | Work items in a stage |
| Set by | The portfolio forum, in Align | The team, with its delivery lead |
| Typical number | Single digits | Single digits per column |
| Protects | Organizational capacity and focus | Flow and lead time |
| Fails when | Urgent requests are added without displacement | Upstream keeps sending more than the team can pull |
The dependency runs one way. A team can hold its limit while the portfolio overcommits, but only by building a queue in front of itself, and that queue is where the organization's real delay accumulates. A portfolio that holds its limit makes team limits achievable, because the number of things competing for each team's attention is bounded before the work arrives.
The WIP limits checklist covers the limit at team level, including what happens when a column is full. This page covers the portfolio decision that sits above it. For how the count got high in the first place, why do we have too many projects goes through the usual causes.
The rest of the vocabulary is in the glossary of agile portfolio management terms. If you are not sure how much is actually active in your portfolio, a 60-minute Portfolio Clarity Session is a place to start, and it ends with what fits next.