SAFe Release Planning Tip 5 - Know your capacity constraints

One of the magical side-effects of building stable teams is the fashion in which it simplifies capacity planning.  No longer is it a question of project managers wrestling with "resource-levelling" in MS Project to ensure maximum utilisation.  Instead of the "resource" being our fundamental unit of capacity, the team replaces it.

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.

Conclusion Part 1

When preparing for Release planning recognise your underlying capacity constraints.  Whilst avoiding the temptation to go too far with up-front estimation, find a middle ground such as illustrated above.  It should well and truly be above the level of "individual specialists", but deeper than "train story points".  Further, recognise that in the presence of numerous component teams normalised story points are of limited value.  They're a very useful tool (and worth the danger) when you have fungible feature teams, but almost irrelevant with a heavy component team mix.  Your real need is "rolled up capacity by class of constraint".

Conclusion Part 2

Whether you have composed your people into feature teams or component teams you will almost certainly have these constraints for your first PSI.  You are most likely starting with a group of specialists who have not yet begun to generalise.  The key difference is this.  As long as you have component teams, you will live with the constraint as your specialists will remain specialists.  If you make the effort to move to feature teams, they will gradually erode the constraints as they take shared ownership and learn from each other.