The case for the SAFe QuickStart

In May 2012 I was struck speechless as I listened to +Dean Leffingwell describe the “1-week QuickStart” model for launching an Agile Release Train on Day 3 of the inaugural (beta) SAFe Program Consultant course.   The coach and trainer in me couldn’t reconcile my visceral reaction to the scale of the event with the confidence with which Dean described the many occasions on which he had employed it.  I drank the kool-aid on much of SAFe, but not that!

Fast forward to September 2013.  With a few more trains and lots of training under the belt I was back in Boulder – this time to spend a week at the new SAI headquarters to participate in the alpha SPCT program.  A very heated discussion took place regarding the pre-requisites for becoming an SPCT.  The proposal to require the SPCT candidate to have completed two QuickStarts caused me to passionately argue that there are many SAFe coaches out there (myself included) who would never buy into running them, and the requirement needed to specify successful launches rather than prescribed launch techniques. 

Fast forward once more to October 2015.  On day 1 of the inaugural SAFe summit in Westminster Colorado, I found myself on-stage describing the fact that the QuickStart is now my strongly preferred model for launching a train. 

So what is the QuickStart and what changed my mind?

One common misconception that needs to be dispelled is the belief that the launch actually begins with the QuickStart (Notice the "Prepare" arrow).  Like any other large-scale event, a great deal of preparation goes into making it a success.  The preparation typically commences with a Leading SAFe course for the leaders of the “train-to-be” followed by a workshop to create a launch plan.   I’ve previously described my preferred approach to this here.

With that cleared up, let’s return to the QuickStart itself.  Whilst PI planning has been strongly advocated by many in the Scaled Agile community, the particular value of starting with the full event rather than employing a “soft-launch” was covered by my colleague +Em Campbell-Pretty in a recent blog post.

That leaves us with the training.  One of the key tenets of SAFe is “train everyone”, but why do we have to do it all at once?  This was the piece that took me years to wrap my head around.  I’ve been training for over 20 years, and throughout that time have loved the intimacy of small classes.  Somewhere between 12 and 20, and you can make a unique experience and form a real connection with every member of the class.  How on earth do you get a high impact training experience with 100 people in the room?

This led to me feeling I knew better than Dean for my first few launches.  I worked with my clients to schedule 4 or 5 team-level courses over the period leading up to the first PI planning.  I’d request that they send entire teams to the same course so they could sit and learn together, and they would promise to do their best.  Then the pain would start.  Firstly, the teams would often be in flux up until the last moment.  Then they would be too busy on current commitments to all come together so they would dribble through 2 or 3 at a time.  And of course distributed team members would go to different courses.  The training was still hugely valuable, but I came to understand the motivation and some of the benefits of the big room – and eventually got convicted enough to try it. 

After the first “big room training”, I was blown away and spent some time sorting through how on earth it could be so powerful.  Following are some of the key insights it yielded:

• The teams will be fully formed. The whole team can sit at the same table. Not only do they get to learn together and share their insights as they learn, but it’s actually a very powerful team formation event. We give teams some time to choose their names on Day 1, and watch team identity grow before our eyes.
• The team engages in collective learning, with the chance to dissect their different interpretations in discussions and exercises. They are not reliant on “1 brain – the ScrumMaster” to ensure they get value from the agile approach, they have many brains who each captured different nuances.
• The features for the PI will be ready. The very long (and effective) series of exercises involving the identification, splitting, estimation and evolution of stories can actually be done as practice on real features the teams will be dealing with in PI planning. 
• Not only do the teams form their own identities, but they begin to form the shared identity of the train. As the discussions and debriefs progress, they start to learn about each other’s worlds.
• Logistics are easier and more cost-effective. You’re already booking a large venue and flying people in – you get to double-dip on both the venue logistics and the return from the investment in collocating people for the planning event.

The biggest takeaway, however, is the momentum that builds.  The team members don’t leave the training room to head back to their old day-jobs while they wait for the train to launch and give them a chance to put their ideas into practice.  The day after training finishes they’re back in the room to apply their newfound techniques.

Now zoom back out to the QuickStart as a whole.    A train succeeds when 100 or so people come into alignment, form a shared identity and sense of mission and collaborate to both execute and learn together.    Can you think of any better way to accelerate the beginning of that journey?

Taking the Status out of Standups

Today was a busy coaching day on a large release train with lots of good coaching conversations.  When I got to the "warm and fuzzy moments" part of my coaching journal at the end of the day, memories of the scrum of scrums in the morning put a such a huge smile on my face that I had to come home and blog.

One of the first things I will do walking in the door as a coach is to go and 'chicken' at stand-ups. 99 times out of a hundred, they'll sound like a status report.  How can it be a self-organising team if they have a daily status report?  It's meant to be the timeout where the team gets together for a moment to work out how best to work together that day on moving towards their goal.  Often, I find the real standup happens just after the formal one.  The scrum-master walks off, and all of a sudden the team lights up and has a great conversation.    

Fixing a standup is a great place to start as a coach.  Changing that one conversation the team is guaranteed to have every day will lay a strong foundation for much of the deeper work to build on.  And I've built up quite a library of tips and tricks from conferences, blogs, colleagues and blind experiments.  The best ones always vary according to the team - I just offer a smorgasboard and encourage the team to pick one or two and try them out.

Simple Tricks for changing the dynamic

Use a talking ball

Very simple technique, takes control of who speaks when out of the hands of the scrum-master and into the hands of the team members. Also bound to get a laugh at some point as a throw goes crazy or when a team member brings in a soft toy that makes funny noises to use as the ball.  It's simple.  Last person to arrive gets thrown the ball.  They speak, then pick someone to throw it to.  Repeat until done.

Start with a soundtrack

Pick a team sound.  A favourite song, a sound-bite aligned to the team's name.  Program an alarm on a phone or a computer to play the sound at standup-time.  It's no longer the scrum-master summoning people in.

Talk to the wall 

There are a few variants on this one.  One is to have the team-member talking step up to the kanban wall and point to the cards they are talking about as they're talking.  Goes well with the talking ball as the person speaking then throws the ball out to the huddle to call the next one in.  Alternatively, have a rotation between the team members of someone to stand at the wall and walk through it from right to left calling for comment card by card.  Changes things up from the "person by person" routine.

Get out of the way

The conversation's meant to be between the team members, if they're all facing the scrum-master while they talk change it up.  They can stand behind the huddle if you're talking to the wall, or when extreme measures are called for make a moving target.  Get the scrum-master to constantly move so there are always other team members between them and the person talking.  It'll move eyelines.

Make a standup agreement

Often a good activity for a retrospective.   Have the team create an agreement listing the ingredients of a great standup.  Make it visible.  If nothing else, it'll prompt a good discussion about why the standup exists.  Many team-members just assume it's meant to be a status report.  Works really well in conjunction with red-cards.

Introduce red-cards 

This is one of my favourites.  Standups that get stuck in the weeds and drag on forever are horrible.  If the scrum-master is forever having to intervene to offline stuff it puts them far too squarely back in the centre.  Establish a stash of pink index cards (or flags or some other fun device) in the standup area and get every team member to pick one up as they arrive.  The system is simple:

• "if you're bored or disinterested in the current conversation, hold up your card"
• "if you agree with someone else who just held up a card, hold yours up too"

Now the team is voting conversations off the island.  They have control, the scrum-master just needs to help park it after the vote - it might be a really important conversation, just not for the whole team

Visualise your impediments

You're trying to discover impediments.  They're important.  They're half the reason to have the standup discussion.  Shame most teams just watch their scrum-master either try to memorise them or take notes while all the conversation is about the status rather than the things stopping progress.  Make an impediment radiator.  Write them up on post-it's instantly and visualise.

Stage a revolt

This one's a bit cheeky, but I've used it a few times to good effect.  Separate the team from the scrum-master.  Make sure they understand that the standup is meant to be for them not the scrum-master, then suggest they go tell the scrum-master they're taking over the standup.  Interestingly enough, the bulk of the times I've used it has been with the scrum-master's full support.  We have a discussion where they explain to me how frustrated they are with their standups.  They try a few things and nothing's working.  Then the team stages a revolt and all of a sudden it's fixed.  

You'll notice a recurring theme above - take it out of the control of the scrum-master and into the team's hands.  But these are no guarantee the right conversations will happen.  They'll almost certainly change the dynamic, but I've saved the best for last.

Change the questions

The "3 question standup" goes stale even faster than the good/bad/confused retrospective - it's used every day instead of every 2 weeks.  What's worse, the questions almost seem designed to promote a status flavour.  And of course, 99 times out of a hundred it's "no blockers" all around even for a team screaming from pain.  Change the questions, change them again.  Find the questions that create the best conversations.  I had one friend who ran for awhile with only 1 question - "What's blocking you?".  And finished the standup by filling in the blocker of the day on the team wall.   See my sample scrum of scrums questions below for some inspiration on new questions.

And .. make sure you visualise the questions.  Nothing worse than team members trying to remember what the question was.  Make a BVIR.  

Scrum of Scrums

This one's easy.  It's just a standup.  All comments above apply, they're just even more important.  Getting a good scrum of scrums going is often painful.  It's typically at more risk of being a status report than normal standups.  Also, never forget a standup is a "daily standup".   The best way to make a painful SoS is to only do it once a week.

So, back to the inspiration to sit down and write tonight.  Today's Scrum of Scrums was for a group of about 10 teams who are 2 sprints into scrum of scrums after spending 8 months without.  And it's been evolving well with some great conversations.  They were just ready for a nudge, and I suggested some new questions to try to the Release Train Engineer last night.  Then I just stood there with a big goofy coaching smile on my face this morning as the richness of the conversation ratcheted up another notch.

For more thoughts on creating a great scrum of scrums, take a look at this post by my colleague +Em Campbell-Pretty delving into visualisation.

Moving from belief to action - implementing WSJF for value based prioritisation in SAFe (Part 2)

In my last post, I described the simulation I use to teach Cost of Delay (CoD) and Weighted Shortest Job First (WSJF).  This often provides the impetus to begin, and one of the beauties of the model is that you can adopt it before you’ve even begun to change delivery method.  Beginning your change with a shared definition of value and a rich supporting discussion is a great launch point!

The first step is to make sure you know your vision and overarching strategy.  This need has usually emerged in the debrief on the simulation.  One group will mention how they paused with 10 minutes to go to say “what kind of city are we really building here?”  Every other group will look around and say “aaah, if only we’d started there!”.   Pulling it back to SAFe terminology, we are looking at the workshop(s) to define the strategic themes and portfolio vision.

With a sound strategic vision in place, we look next at adapting the model to the organisational context.  Three key questions need to be answered:

• Do we use Dean’s components for CoD?
• Do we weight the components equally or otherwise?
• What specific factors contribute to each component?

The official SAFe formula is:

Cost of Delay = User/Business Value + Timing Criticality + Risk Reduction/Opportunity Enablement

Typical variations I have seen include:

• Separation of “Business Value” and “Customer Value”
• Separation of “Risk Reduction” and “Opportunity Enablement”
• Introduction of a component for “Alignment to Strategy”
• Weighting Business Value more highly than the other components.

In practice, I prefer to defer the weighting question.  Revisiting it once you have scored a set of options and gained a feel for how you are scaling each component seems to land you in a better position.

Another key theme that always emerges in the simulation debrief is the importance of getting to a shared understanding of ‘what contributes to’ business value, timing and opportunity/risk reduction.  Groups will discuss how alignment around scoring became easier as they aligned around the definition of value.  They’ll also regularly highlight the fact that once they got to opportunity/risk reduction they realised they had been ‘double-counting’ it in earlier components.

Leveraging this insight, my next workshop after the strategy is defined beings with identifying the contributing factors.  This is fairly easily facilitated with flip-charts and post-it’s, and typically takes 60-90 minutes.  Again, it becomes an alignment tool as it enables a great discussion on what constitutes value and opens up shared understanding among the group.  Below is a (slightly desensitised) example of the definition from a group I recently helped develop a roadmap using WSJF.

By this point you have an overarching strategy, a model people understand how to use, and you’ve filled in and clarified the intent in using it.

The next step is to take your current list of opportunities and get them estimated.  Most groups I work with want to retain the index card/planning poker approach.  This is handy, because every good coach knows how to help people navigate a good planning poker estimation session.  I will also often separate the estimation to one workshop per contributing lever.  The conversation is intense, and with a decent size backlog (25-30 items) allowing a couple of hours per component works well.  It also allows time for homework and clarifications.  We regularly park a couple of items for people to go away and assemble supporting data.  We conclude the series by pulling all the calculated results together and reviewing/adjusting the result.  Once your first list is prioritised, you just need a cadenced working group to evaluate new items or adjust previous evaluations as new information emerges or timing considerations change.

My closing hint is to remember not to be a slave to the numbers.  There are often good reasons to adjust the final ordering.  And naturally you want to put a kaizen approach in place to start to measure realised benefits and use that feedback to improve your initial value estimation discussions.

The true value is not in calculating WSJF to 2 decimal points.  It lies in having a tool that facilitates objective conversations that assists a group of execs or product managers in aligning around a common understanding of value for the organisation.  In doing so, it’s amazing how much they start to understand about each other.

Getting from theory to practice with Cost of Delay and WSJF in SAFe

Recently, I’ve noticed a number of threads on the SAFe linked-in groups indicating people are struggling to get started with the SAFe “Weighted Shortest Job First” (WSJF) prioritisation model.

When I first heard +Dean Leffingwell teach the model I thought “wow, this fantastic.”  His use of a proxy model for Cost of Delay (CoD) seemed inspired.  +Don Reinertsen  had provided compelling arguments for the power of fully quantified CoD.  On the other hand, all too many people abandon all attempts to have a value discussion because it’s “just too hard to quantify”.  The 3-part proxy in SAFe seemed simple enough to enable people to begin.

The problem, I learned, was one often encountered in people digesting Don’s principles of product development flow.  It sounds like fantastic theory but the complexity makes it challenging to find a starting point.  My first breakthrough came in early 2013.  I was teaching a public Leading SAFe class, and had 5 people from one company on the same table.  While most people tackle the WSJF exercise as individuals, this group had a shared list of features and attacked it as a group exercise.  They made up planning poker cards from post-its and started voting.  As I listened to the conversation, I got inspired.  Not only did I hear a great discussion, but I could hear what they had misunderstood from the theory.

My next step was to take their example and turn it into something every class member could experience.  They’d had the benefit of a list of features all of them recognised, but this is rarely true.  For an answer, I decided to feed every group a recognisable set of things to debate for Cost of Delay.  The result was a simulation I call “SAFe City”.  The setting involves a property developer building a satellite city and evaluating the Cost of Delay of various housing estates, shops and other developments.  Initially framed at the Epic level, every group receives a list of 9 Epics to evaluate along with a good supply of planning poker cards.

I started to run it for every class.  And the results astonished me.  Not only did it become apparent how confused people became in interpreting the theory, but I also started to understand the true beauty of the model myself.

Sample Epic

If you’re interested in the simulation, it takes roughly 1 hour to run and debrief and all the required materials can be found at SAFe City Epic Prioritisation.  It runs perfectly well standalone, and I’ve run it with groups up to and including C-level.

The activity gives groups both the confidence and interest to take it back into their own context.  I’ve now seen numerous groups elect to adopt the model irrespective of whether the initiatives are being delivered through waterfall or agile.  In my next post I will tackle the first steps as we take it out of the classroom and into reality.

Self-selecting teams with SAFe

Whilst the energy surrounding the launch of an Agile Release Train is immense, there is an all-too-real risk that our new teams will be more facade than reality once the hype dies down.

Forming around the delivery of value, we draw a "kidney shape" that inevitably cuts across significant organisational boundaries.  In so doing, we ask both line management and team members to take a major leap out of their comfort zone.

Whilst as agilists we love the mantra of "embracing uncertainty", it is far too easy to gloss over the human impact this creates.

For line management, it involves a significant amount of release.  No longer will they determine the day to day priorities of those they manage.  Much as we rail against traditional performance management, it does not disappear overnight.  How will they address this in a matrixed world?  How will they address their duty of care with respect to career progression?  How do they deal with a situation where some of their people are embedded in a train and some not?  What happens when they lose their "go-to" problem solvers to an agile team?  Do they really understand what "dedicated team member" means?

For team members, the upheaval is even greater.  No longer will they be surrounded by others with a similar skill-set and conversational language.  In many cases, their new team-mates will be people they have literally thought of as "the enemy" for years.

There is a pattern I have been guilty of and heard from fellow coaches many times around the design of teams for a new train.  Full of passion to create "self-organising teams", enable decentralisation, and change our language from "resources" to "people", we fill a room with leadership.  Wanting to be agile, we bring lots of post-its.  We put flip charts on the wall (one per team), put people's names on color-coded post-its (blue for devs, red for testers, green for BA's etc etc).  Then we allocate them.  Who goes where?  How do we get a balanced team?  Can we stick to "100% committed" and avoid "shared resources"?  Full of our triumph at our "agile team selection process", the workshop concludes with a moment to form the "Comms plan" for announcing the new team structures.

Do the leaders in the room really understand what they're committing to?  Do they feel safe to voice their concerns?  Do we know the personalities and personal histories of the people we are teaming up?  Are we discussing people or post-its?

Any hesitation in answering the questions above in the affirmative will likely undermine our train.  But beyond that, doesn't this feel like a very management-centric approach to creating "autonomous self organising teams"?

I've felt for a long time that there has to be a better way.   I've been reading for years about the power of self-selecting teams.  I've loved it not just from the "team effectiveness" perspective but also when thinking about the psychology of change.  Every Agile coach knows that people dislike having change forced upon them, we should be trying to create the conditions in which people can be part of choosing the change for themselves.  But I just haven't been able to bring it to life.

Then last year I read a blog post by Sandy Mamoli of Nomad8 about "squadification", and I was in awe.  She had convinced an entire IT department to throw their current structure into the air and hold a 1 day event which enabled all their people to organise themselves into new Agile teams (or squads).  She had been generous enough to share her facilitation design, and as I read it light bulbs started going off in my head.

Her premise was that the job of leadership was to design the teams, their missions and the skill-sets they would need available to fulfil them.  So far so good, this is what we're doing when we commence the design of a release train.  Then, you  hold an all-day facilitated event where candidate team members self-organise themselves into the teams whose shape you have defined.  What a replacement for the "people as post-its" workshop!

I was fortunate recently to be coaching a train with a courageous leader.  They had originally formed with component teams, were looking to re-organise into feature teams, and he shared my excitement about Sandy's thinking.  In the spirit of servant leadership, he did not want to thrust it upon his leadership team but invited me to facilitate a series of workshops with them to explore it.

Three weeks and many nervous moments later, we embarked on a "Team Fair".  He has shared the story on his blog, and I have to say the result was amazing.  The vast majority of our "What if?" scenarios about things going wrong did not eventuate, and some very surprising and creative outcomes did.  In designing it, we had the chance to explicitly redesign the role of line management in the new world and give them the time to walk their people through the upcoming change and involve them in the preparation.  The fair itself became a symbolic moment as leadership "released" their people into the freedom they had designed.

With every train I help to launch, I take away some new learnings for the next one - backed by the conviction of experience to give me the courage.  Facilitated team self-selection through a "team fair" is now firmly in the kitbag, with thanks to +Sandy Mamoli for the inspiration and +Andy Kelk and his team for the courage to experiment.

SAFe Release Planning Tip 6 - Scaled Planning needs Scaled Facilitation

Watching a great facilitator in action can feel like being in the audience for a magic show.  You cannot understand how they're doing it, but somehow they invite people to be present and give of themselves while creating the safety and energy for true creativity and alignment to emerge.

It's been a large part of my work for many years, and I know that for a long time when people asked me to explain my secrets I was unable to answer.  Eventually, as I spent time with amazing facilitators like +Jean Tabaka, +Gerald Weinberg and +Esther Derby I started to understand the science and recognise why some of the things I did worked.

A facilitator's first desire is for every person in the room to have a voice, and to be engaged from the moment they enter the room.  Their second is for the workshop to align these divergent voices, enabling them to leave the room with both shared insights and shared commitment to the outcomes.

The SAFe Release Planning event is both the dream and the nightmare of the facilitator.  As a dream, it provides the canvas of 100 or so people and 2 days to work.  As a nightmare, it asks that you keep 100 people fully engaged in tough often contentious work for 2 days.  The first secret of facilitation is to create the safety for every participant to be heard, understood and valued - incredibly hard to create, observe and address in large groups.

Draft Plan Review

So, how do we do it?  The good news is that it begins with basic technique rather than "art".  When coaching facilitators, I return again and again to the message that you do half of your facilitation before you ever enter the room.  You do so by creating a structure to facilitate to.  How will you use the space?  What tools (or activities) will you use for each phase of the workshop?  What supplies will you need?  How will you "set the scene" visually to engage them when they walk in the door?  What will they see?  What will they hear?  How will you create movement?  With the right preparation, you can focus on observing, inviting and steering with minor interventions.

The really good news is that the SAFe Release Planning Facilitation guide in every SPC's toolkit provides you with a fantastic starting structure.  The influence of +Jean Tabaka  (the "Queen of Collaboration") in +Dean Leffingwell's formative work at BMC is readily visible, as is the polish applied through the dozens if not hundreds of events in which it has been applied since.

The agenda sets the scene for an orchestrated dance of scene setting (vision briefings), divergence (breakouts), convergence (plan reviews), check-ins (scrum of scrums) and closure (confidence vote).  The Program Board and Team Breakout setup guides provide a visual structure to facilitate to, as do a number of the additional tools such as a Feature Planning Kanban that I've suggested earlier in this series.

Program Board

However, there's a catch.  Once the dance starts, the most important tool in the facilitator's arsenal is observation.  They must be able to see and hear the moments when intervention is needed, and observe them clearly enough to intervene effectively.  You can do this for 20 people, but how do you do it for 100?  

Additionally, a typical workshop breakout would be measured in minutes and intervention can occur when the groups converge back from the breakouts.  But we have breakouts that last for hours.   Our overarching structure requires supplementation at a more granular level.  Those long breakouts themselves need to be designed and facilitated.  

Team Breakout Space

If you spend any amount of time with Jean, you will learn the importance of facilitation planning.  Personally, I generally allow 1-2 hours of planning/prep time for each hour of the workshop.  Jean generously reviewed this post for me, and observed that her team at Rally have found that very large workshops tend to take even more than 2 hours per hour of the meeting. This is not "logistics, invites and powerpoint" .. it's facilitation design.  And if you're working with a facilitation team, it needs to be shared time.  

The reality is one facilitator cannot do this, no matter how heroic their skills.  You need a team.  And that team needs the fundamental skills to enable an amazing event.  The chance that your brand new Release Train has a ready made team of facilitators is near-zero - you need to create one.   My recommendation would be that your team consists of at minimum the primary facilitator and one per team (ideally your scrum-masters) for the breakouts.  Ideally, you'd also have a secondary facilitator dedicated to folks such as stakeholders, product managers and architects who are at risk of becoming disconnected or lost during the breakouts.  This team needs 2-3 days workshopping together to prepare the facilitation plan for the first event.  

As you create the plan, make sure the whole team owns the whole plan.  At no time should a facilitator be thinking "I'm off-stage now" and signing out.  It's a synergy.  If the objective of a particular "whole train" moment is going wrong, the small group facilitators can rescue the day through adding the right powerful question from the crowd.  Likewise, the main facilitators should be roaming constantly during the breakouts.

A rough plan of attack is to look at each segment of the agenda and ask the following questions:

• What is the objective of this segment?
• Who is "on stage" for facilitation?
• Who is "off stage" and how might they help?
• What does success look like?
• Who are the main players?
• Who is likely to be less involved, how can we keep them connected?
• What facilitation tools will we use?  Do we all understand how to use them?
• What materials and preparation do we need?
• How will we capture the key takeaways?
• What is likely to go wrong?
• What is the ideal time box?  What's the minimal time box?

Once the event arrives, make sure the facilitation team has an open/close for each day and a retrospective after the event to support their own inspect & adapt cycle.

Like much of this series, the tips offered here are lessons learnt through failure.  For my first event, I took the "heroic facilitation" approach.  I worked with the RTE to create the facilitation plan.  It was a great plan, and we were very proud of it when we shared it with the scrum masters so they were clear on their responsibilities.  And I started writing this post in my head about 10 minutes into the first breakout.  We survived it, the energy was great, and the stakeholders were blown away.  But it could have been so much more if I'd remembered Agile 101 - "the team that's going to do the work should be the team that creates the plan".

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.