A Lean Perspective on SAFe Portfolio WIP Limits
by Eric Willeke, SAFe Fellow, SPCT,
As a field-practicing SPC, I’ve noticed a few nuances that are important to understand when discussing how the portfolio level in SAFe is Work in Process (WIP) limited. The details can be a bit hard to assemble from the site, and while they are clearer in the portfolio module of the Leading SAFe Course, I wanted to describe how I interpret and apply this concept in the field.
I’ve highlighted and combined the four ways in which SAFe provides implicit and explicit WIP limits around the portfolio. These ways do not map directly to the Kanban states in the Portfolio Kanban.
Epic Analysis flow: The only explicit, count-based limit in the portfolio kanban in SAFe is limiting the number of epics permitted to be in analysis and pre-approval at any given time. SAFe recommends the WIP constraint here is determined based on the desired epic throughput (pull rate from portfolio backlog into implementing) and the availability of the architectural and development capacity to perform analysis. In the past this was framed as “limited by the number of epic owners”, but this didn’t properly represent the bottleneck. Reference
Portfolio backlog: While there is no explicit limit set to the portfolio backlog size, in practice it has an implicit limit based on desired aging and investment flow characteristics. If items in the portfolio are consistently being passed in the final cost of delay sequencing, they are candidates to be pulled out and eliminated or passed back through the analysis flow for reconsideration and rescoping. Remember, the portfolio backlog is not a linear queue, instead, it is continuously reprioritized as newly approved epics arrive.
Implementation: There is an explicit, flow-based capacity limit between the portfolio backlog active implementation by the various trains. The limit is managed as an explicit pull system where the trains may pull in the work at the cadenced PI boundaries if they have capacity to support it. Forecasting and capacity recognition is done in “big round number” story points, generally derived from reference class forecasting or relative estimation approaches performed against a preliminary feature decomposition. Reference. Capacity may be reserved by allocating budget against the epics, representing an explicit, cross-cutting investment decision by the executives forming the program portfolio management team. Reference.
Portfolio Distribution: SAFe significantly simplifies the decision making around the above concerns through the recommended budgeting approach, which explicitly allocates budget, delegated financial authority, and scope determination to the release trains as the default approach. This leads to a significantly reduced portion of the overall spend being managed as explicit items in the portfolio flow. Instead, the majority of the work can flow “horizontally” at the train level without incurring the administrative and governance overhead associated with the larger items flowing through the portfolio backlog. The Portfolio Kanban System flow is intended to be for portfolio epics (items that cross trains) and/or program epics that are of sufficient size that they need explicit financial governance. Reference. SAFe additionally provides an optional value-stream level to manage coordination of those cross-cutting items that demand additional attention, due to the various dependencies that remain after making the organizational structure trade-off decisions without adding the additional financial governance overhead. Reference
In my experience working with organizations consulting and training SAFe, this final aspect is the hardest part to adopt organizationally, as it incurs the same set of challenges that evolving towards an incremental funding / Beyond Budgeting approach does. As a result, these organizations tend to flow a much higher percentage of their work through the portfolio kanban than should be necessary and incur the significantly longer lead times associated with doing so. They also tend to enter a negatively reinforcing loop of excessive cross-train dependencies and failure to achieve multi-train continuous improvement. I know a few companies that have navigated their way through this trap, but it is one of the bigger SAFe anti-patterns I’ve observed, at least early in adoption efforts.
Last update: 5 May, 2020