SAFe takes this to the next level by composing a group of teams into a release train - allowing us to move beyond team capacity to train capacity. Traditionally, this view of rolled-up capacity is impossible since team capacity is measured in story points and different teams use local definitions of a point. Albeit contentiously, SAFe resolves this by suggesting the adoption of normalised story points - allowing us to roadmap based on a "Points per PSI" capacity for the train.
The selection of feature mix to take into a PSI utilises the following elements:
- Train capacity (how many/how big)
- Capacity allocation (proportions for different feature types)
- WSJF (prioritisation of features within each class of capacity)
To illustrate using the "GeekBooks" online bookstore metaphor from the Leading SAFe simulation, picture the following:
We are employing three classes of capacity with allocation based on our opening business strategy:
- B2C (Purchasers of books) (50%)
- B2B (Suppliers of books) (25%)
- Architecture (25%)
Following relative sizing and WSJF assessment of the features in the Program Backlog, we might have the following:
Assuming a train capacity of 500 points for the PSI, the following would be selected for PSI planning:
- B2C (Flexible Search, Book Browsing, Shopping Card) (240 points)
- B2B (List New Title, Alter Pricing) (120 points)
- Architecture (Active-Active, Internationalisation (120 points)
But there's a catch. This wonderfully clean formula only works if the train contains nothing but Feature teams and any team can pull any feature. In a world with multiple flavours of feature team you now have capacity constraints based on feature flavour. If you further complicate it by having component teams, you must also factor in component capacity constraints.
Imagine that the release train has the following makeup:
- 2 x B2C Teams (capacity 100 points each)
- A B2B Team (capacity 100 points)
- A middleware component team (capacity 50 points)
- A "Back-end" component team (capacity 150 points)
Whilst the initial strategy assumed 3 classes of capacity driven purely by economic strategy, in reality we have 4 flavours of capacity constraints. We can still "roll the dice", enter PSI planning and wait for the management problem solving session to apply tradeoffs between economic priorities and real constraints. I've been there, and the power of the event is that it helps you navigate exactly this situation.
But ... we can also smooth our life out with a little more up front feature refinement. If we know we actually have 4 types of capacity constraint, why not take our feature-level estimation down one layer of granularity. Applied to the first example, we might see the following:
We now know our previous feature set requires the following:
- 150 points of B2C capacity (under by 50)
- 90 points of B2B capacity (under by 10)
- 70 points of middleware capacity (over by 20)
- 190 points of back-end capacity (over by 40)
At this point, there are various ways to respond. Deferring the active-active feature is obvious. Finding a small "client-side only" feature would make sense to take advantage of our spare B2C capacity. In reality, the management problem solving session at the end of Day 1 deals with a scenario this simple easily. However, we still have no idea what other problems will be exposed during the draft plan preparation process. Additionally, teams will have wasted breakout time that could easily have been avoided.