In light of the discussion over at kanbandev about the feasibility of how SAFe’s WiP limiting approaches work at the portfolio level, there are few nuances that are important to understand. (I've included references below for more information at the Scaled Agile Inc. website, and more information can also be found in the portfolio module of the course materials.)
Epic Analysis Flow
The only explicit, count-based limit in SAFe's portfolio Kanban is limiting the number of epics permitted to be in analysis and pre-approval at any given time. SAFe recommends that 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)
While there's 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.
There's 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 on the program portfolio management team. (Reference)
SAFe significantly simplifies the decision-making around the above concerns through the recommended budgeting approach, which—as a default approach—explicitly allocates budget, delegated financial authority, and scope determination to the release trains. 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 flow is intended to be used only for those items that cut across trains and 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 a incremental funding or beyond budgeting approach does. As a result, these organizations tend to flow a much higher percentage of their work through the portfolio 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.
This post originally appeared at Eric Willeke's blog.