Bringing your SAFe PI Plan to life during execution

Introduction

The SAFe PI planning event leaves every team on the Release Train with a beautifully organized backlog identifying everything they need to do together to succeed in meeting their PI objectives.

However, as we’ve learnt from military strategist Helmuth von Moltke, “no plan survives contact with the enemy!” The scale and energy of the event makes it easy to fall into the trap of believing we’ve created a plan that will survive and inherited mindset drives the belief we “now have a plan to manage compliance to”. It’s easy to miss the fact that what teams are committing to is their objectives. The carefully identified backlogs and dependencies are simply things we have produced to help us understand the outcomes we believe are possible and a point-in-time representation of the best approach to achieving them.

Successful execution relies on us remembering that backlogs must live. Estimates will be wrong, stories will have been missed, we will discover more innovative ways of achieving the objectives.  In short, circumstances will change. PI planning provides a great start by launching the PI with 5 to 10 teams having beautifully coordinated and well-groomed backlogs but success rests on what we do with them once we leave the room.

All too often, I see new teams and trains treat the PI plan as a static artifact. Your plan should always reflect your current best understanding of the situation, and the primary representation of your plan in SAFe is your backlog. Having previously covered the ongoing lifecycle of the individual backlog item, I will focus here on the of principles and practices I have found most useful in helping SAFe implementations manage the plan as a whole.

The importance of visual management

Any scaled agile implementation will inevitably wind up using a digital tool. But PI planning itself gives us the clue – it’s an amazing collaborative planning event enabled by physical visualization of the plan. If you want your plan to live, physical visualization is essential. By all means, be responsible and keep your digital tool up-to-date – but recognize it for the information refrigerator it is. I’ve seen all the tools used both well and poorly, but I’ve never seen a tool enable effective ongoing collaborative planning to anywhere near the level and efficiency possible with physical visualization

The Team PI Plan – from Planning Room to Team Room (PI level visualisation)

I have a starter template for team level plan visualisation that I suggest to all the teams I coach. It works best when a large horizontal space is available and it can be organised in one continuous run, but most teams can find space for it with a little ingenuity. As a template, it looks a little like the following:

Every area except the Inbox and Overflow (covered later in the article) will contain an indication of planned velocity and load (as represented by current contents). Additionally, PI objectives should be somewhere prominent (preferably next to current sprint).

Team Master Builders: Mobile wall, top row is current sprint, middle is next spring, bottom future sprints

Team Olympus: Current to future from right to left

Team Nintendo: Current sprint on right window, next sprint on middle, future on left

Additional details for each area follow:

Current Sprint 

This is the visualization every team should have for their current sprint – often known as the Scrum board. Not the focus of this article, but it’s always good to bring it to life.

Olympus Current Sprint: Take every opportunity to build team identity through visuals

Next Sprint

The upcoming sprint gets slightly more focus than other future sprints, as this is where we are getting our stories to “Definition of Ready”. Typical swimlanes might be “Prioritised”, “Specifying” and “Ready. Operation of this wall is covered in my last post on story lifecycle

Team Pixar: Next sprint helping manage movement of stories to definition of ready

Future Sprints

These areas basically mirror the content from the PI plan. The backlog items and their intended sprints are carried out of PI planning and placed straight into their spot in the team area. As each sprint concludes, the cards move to the right to indicate the shrinking number of future sprints left in the PI.

Extended Backlog Tools

Given that the backlog represents “all the work” for the team, it is a great place to capture other activities which are not necessarily either classical “user stories” or “tech stories”. Working with ARTs, we regularly devise “specialty card types” to help them articulate and manage their plans. The two I use most frequently are “Commitment Cards” to help with team-level dependency visualisation and “Capacity Cards” to represent “work that’s not necessarily very agile but definitely necessary and often responsible for killing a team if they fail to plan for it”.

Commitment Cards

I was introduced to this concept by Craig Larman and Bas Vodde’s Scaling Lean and Agile Development, and have found it invaluable in SAFe. The identification of dependencies on the Program Board during PI planning (and fun with red wool) is one of the most visually powerful tools in SAFe, but little formal coverage is given to reflecting them at the team level.

The notion of a commitment card is that when one team makes a commitment to another they place a (0 point) story in their backlog describing the commitment made. The recipient also records the commitment in their own backlog as a 0 point story.

This assists on a number of fronts. Firstly, a dependency is rarely on a single story – it typically operates at a higher level of abstraction. Secondly, it becomes a first class citizen in the team’s backlog refinement activities.

Finally, it assists teams populating the program board with achieving an appropriate level of granularity when reflecting their dependencies. The commitment should already be written at the appropriate summary level of granularity, and can simply be duplicated onto the program board. If the commitment card shifts in the course of planning, its twin on the program board needs to shift.

Capacity Reservation Cards

Many teams have work which cannot specifically be planned for but is nonetheless reasonably predictable in size and timing and must be catered to. Whilst team-level capacity allocation is one option for dealing with this, it’s a reasonably blunt instrument which does not cater to situations where the scale of the reservation required varies from sprint to sprint.

The most common cause of this comes in the form of hardening activities. We all know good agile doesn’t rely on hardening, but many enterprises face the harsh reality that the elimination of extended hardening periods will require dedicated work over the course of years. For example, I routinely work with organisations which have some form of enterprise-wide release process that spans 6-12 weeks. We tend to find that the capacity of a train is divided between implementing the features for the current PI, supporting the progress of features from the previous PI through the enterprise release process, and providing warranty support for the previous release. This is particularly prevalent where mainframes, ERP systems and other major COTS implementations form a major component of the technology stack.

The bulk of work for teams arising out of these processes will be unplanned (eg defect fixes, incident resolution), but the intensity of activity and likely volume of work is more predictable. In these situations, we will place “Capacity Reservation Cards” in the backlog setting aside a certain number of points in the team’s capacity to be available.

An additional use we make of this is setting aside capacity for the team to participate in ideation or “discovery workshops” on upcoming features as they are prepared for the next PI. Whilst the IP sprint in theory provides capacity for this work, it has the effect of creating a late-stage batching effect on team involvement in feature preparation. Inserting “Feature Discovery” items in the backlog allows time to be set aside for the team sprint by sprint and spread these activities over the whole PI.

On a closing note, the usage of this technique enables one of my favourite PI metrics – “% of capacity required for hardening support”. Downward trends in this metric indicate the effectiveness (or otherwise) of efforts to bring forward quality and minimise the need for downstream hardening.

Managing Change

Whilst as agilists we “welcome changing requirements”, there is a reality that at scale these changes will have impacts and often those impacts will extend beyond the team directly dealing with the change. A chaotic world where the backlog is constantly changing and the impact of these changes is not discovered until late in the PI is not a great thing to have.

As such, I have found two tools to be very useful – the “Inbox” and the “Overflow”. The Inbox provides us with a mechanism for managing the introduction of new items to the backlog, and the Overflow helps provide visibility of backlog items at risk of not being completed within the PI.

Inbox 

As new stories are identified by the product owner (or others), they are placed in the Inbox as a holding area. The team can then establish ceremonies with the Product Owner for incorporation of new items into the backlog. Common agreements would include the team (and PO) achieving shared understanding of the backlog item, converting it to user voice form, estimating it and deliberately considering the prioritisation as it is inserted into the backlog.

Team Pixar Inbox and Overflow

A little humor from Team Aliens: Guess which is the overflow :)

Overflow

As reality occurs, new backlog items are discovered, actual velocity is realised and planned velocity is updated this area comes into play. Any backlog items for the PI which will not fit based on the planned velocity are moved to the overflow to highlight the priority decisions being made by the Product Owner.

Backlog Refinement

Whilst supporting the sensitivity that led to this practice acquiring its new name, the unfortunate reality is that it most commonly seems to lead to people missing the key activity. Knowing that story elaboration is taken care of through specification workshops, the primary focus for refinement becomes the management of content and priority of the PI backlog for the team.

I generally place this on cadence either once per week or once per sprint as a one hour session. It is the responsibility of the product owner, but best performed as a shared activity with the scrum master. As this is an alignment activity, I also look for all teams on the train to schedule their backlog refinement session on the same day (leaving it open to the team what time of day). Motivations for this will become clear when we proceed to Program Backlog Refinement.

Key activities will include:

• Updating velocity forecasts: This is obviously data provided by the scrum-master, but may shift either based on yesterday’s weather or as team leave comes into focus. 
• Process the inbox: All stories from the inbox which have passed through the established entry conventions should be inserted into the backlog in the relevant sprint based on the product owner’s priorities. 
• Adjust scheduling to match capacity: Based on the updated velocity forecasts (and any newly incorporated stories), any overloaded sprints should have stories shuffled back down to future sprints until the load level falls below forecast velocity (or other agreed load constraints). This will often result in stories from the final sprint in the PI being moved into the overflow. 
• Validate commitment cards: Cast an eye over all the commitment cards in the backlog, asking the following questions: 
• “Will we still be able to honour this commitment?” 
• “Will this reprioritisation affect a commitment we’ve made?” 
• “Do our changed circumstances mean we no longer require another team to meet the commitment they have made to us?” 
• Adjust priorities: Now that the backlog has incorporated the inbox and been adjusted based on capacity and commitments, review for priority updates. At a bare minimum, take a good hard look at the overflow area and see whether any of those cards need to be traded back in and others demoted. 

On a final note, I suggest using a flagging system during refinement. Place a flag (and accompanying note) on any card that moves. This supports the following:

• Updating the digital tool to reflect any changes made to the physical backlog. 
• Updating the team at standup the next day on the outcomes of the refinement session. 
• Informing program backlog refinement. 

Program Backlog Refinement

Whilst not formally specified in SAFe, I have found this to be an essential extension as a synchronization event. You will recall that all teams put their team level backlog refinement session on cadence to occur on the same day. We leverage this by placing the program backlog refinement ceremony on the following day. Quite often, we settle on Thursdays for teams and Fridays for the program. This is based on the fact that teams commonly adopt “Wednesday to Tuesday” sprints. You’re then refining the backlog the day after Sprint Planning (to reflect any updates coming out of the planning session) and on day 7 of the sprint (by which time you’ve discovered some new surprises and have a good clue of any stories which might slip the sprint boundary).

The ceremony has two phases – often with slightly different participation:

Team Updates (<30 minutes)

Attended by the RTE, Product Manager, ScrumMasters and Product Owners.

All teams provide an update of any outcomes from their backlog refinement session which may affect other teams. The focus is on moving or at-risk commitments. Typically held at the program level visualization (whether it be program board or something else).

Overflow Review (30-45 minutes)

Attended by the Product Manager, Product Owners, RTE and potentially other stakeholders.

This is a “management by walking around” exercise. The group moves from team area to team area, with a particular focus on the contents of the overflow areas. Using the flags applied during team backlog refinement, the product owner walks through the outcomes of the previous day’s refinement and validates their prioritization calls.

It provides the group with insight into areas where the overflow is mounting or critical commitments are entering high-risk status. This information can then be fed into the release management meeting to support program level decision making on moving scope to other teams or establishing effective mitigation strategies.

Conclusion

An agile plan lives. In the spirit of transparency, it always reflects the current reality and beliefs of the train. It is critical on many fronts:

• Supporting a team maintaining ownership of their larger commitments, avoiding the trap of living only for the current sprint and losing sight of their commitment to a broader mission. 
• Supporting ongoing synchronisation of plans across all the teams in a train 
• Supporting effective trade-off decision making by the Release Management Team 
• Providing early warning to support effective mitigation activities as the plan fails to survive contact with the enemy. 

The PI planning event provides an amazing springboard, but effective planning must be continuous and based on a transparent reflection of reality. Utilising cadence and synchronisation as enablers, the practices described above are simple to implement and will provide astonishing contributions to maintaining the alignment, transparency and focus of a Release Train.