SAFe Release Planning Tip 4 - Consider "Feature Breakouts" as well as "Team Breakouts" if you have component teams

SAFe proposes a number of team flavours.  All are cross-functional insofar as they are able to "Define, Build and Test a thing of interest".  The suggested "things of interest" are:

• Features
• Products
• Components
• Subsystems
• Interfaces

Realistically, the flavours can be further condensed into either  "Feature" or "Component".  A "Feature team" can fully deliver a "Business Feature", whereas a component team can typically only deliver "technical components of a Business Feature".  On the other hand, component teams can quite often fully deliver "Architectural Features".

Countless books, articles and speeches have been devoted to the benefits of Feature teams, but the reality is many if not most trains will launch without them.  Most will contain a mix of "psuedo-Feature teams" which can nearly deliver a business feature and supporting component teams.  Typically, 3 factors contribute to the presence of component teams:

1. Insufficient people with a given specialisation to provide one for each team
2. Technical and environmental constraints 
3. Lack of conviction of the benefit to aligning at the team level around valued outcomes rather than technical proficiency

The net result is that the vast bulk of features will require contribution from more than one team.  Typically, the "pseudo-Feature" teams will take ownership of business features and look for contributions from the component teams.  The component teams, on the other hand, will often take ownership of architectural features and expect to provide contributions to the business features.

In the context of SAFe release planning, this can all too easily create the following scenario when the Team breakouts start on the afternoon of day 1:

• From 1:00-3:00 the "psuedo-Feature" teams work with their product owners and managers to understand the business features they are tackling and break them down into stories.  As they work, they identify needs they'll have from the component teams and assumptions as to what form they'll take and they place these in a pile ready to hand over.  They may visit the component teams during this time, but are likely to be given short shrift as the component teams are deep inside "their own features".
• From 1:00-3:00 the "Component" teams work with the architects on the architecture features in the program backlog and break them down into stories.
• From 3:00-4:00 the feature teams land on the component teams with a pile of stories they need estimated and scheduled.  The component teams, with little understanding of the context, look at the stories and say "they're wrong, we're going to need to rewrite them" .. while the feature teams say "but we need you to estimate and schedule them so we can lock in our plan".
• At 4:00, the draft plan review exposes a litany of unvalidated assumptions and bottlenecks around interactions between the feature teams and the component teams.
• On Day 2, the feature teams and the component teams work together to translate the feature team needs into technical stories for the component teams to deliver .. with the product managers and owners relying on the feature teams to represent their needs as they've "already conveyed the business context and don't understand the geek-speak".

What I suggest is to both leverage flow-based planning as described in Tip #3 and different types of breakouts.  As part of your program backlog preparation, identify the features which are heavily interdependent across teams.  When choosing the priority order for planning, consider planning these features first.  Inevitably, you will wind up with a plan where the scheduling of these features dominates and the more contained features are scheduled opportunistically into the gaps left.

When breakouts commence, rather than going directly to team breakouts go to feature breakouts.   Your "pseudo-feature" teams pull features, and collect representatives from each component team to join them for the initial breakout.  The focus of the feature breakout is then:

• Establish shared understanding of the feature
• Elaborate any further feature acceptance criteria as necessary
• Break the feature down into team-based stories with high-level acceptance criteria
• Identify key dependencies between stories that cross team boundaries.

Once the heavily interdependent features have each been through their feature breakout, return to team breakouts - with team members taking their stories with them.  Once back in the team breakouts:

• For each feature from a feature breakout:
• Members share the stories created during the feature breakout with the rest of the team, obtaining further clarifications as necessary
• Estimate as a team
• Load stories into sprints in-line with inter-team dependencies
• Close the feature out on the program board
• Progress through feature breakdown and planning for remaining features team owns. (Those with little or no dependencies on other teams).

Personally, my experience with trains containing a mix of feature and component teams has been that you wind up with features which are "rocks" and "pebbles".  Those features which span multiple teams for delivery tend to be the rocks that dominate your PSI plan.  Once you have these, you find the more contained "single team features" become the pebbles that are slipped through the gaps in your PSI left after the rocks.  Making sure you bring a mix of "rock and pebble features" into the PSI priority list is the first enabler, and adjusting your breakout structure can become a huge time saver both within PSI planning and execution.

What's next?

• Tip #5 - Normalised story points don't tell the whole story - know your capacity constraints
• Tip #6 - Every breakout deserves a good facilitator