Running Effective Planning Events

Related webinar series

Related articles

Related pages

Related Content

Recommended resources

Online learning

Provide Feedback

For mid to large sized organizations, the Planning Event has become to “scale” what the Daily Scrum is to Scrum. Whether or not you are doing SAFe®, the Planning Event is often a great way to increase collaboration while coordinating the work of your teams. This article is geared to those people who have adopted the SAFe Program Increment (PI) Planning Event, either while doing SAFe or not.

Planning is everything, even in Agile

Eisenhower famously said, “plans are worthless but planning is everything.”

The purpose of planning in Agile is not to create a plan to stick with it. It is to increase collaboration, to discover dependencies, to create a baseline for working together and provide some degree of predictability to stakeholders.

Planning events can be improved by shifting from the plan itself (which is worthless) to increasing collaboration and dependency management. On reflection, it is easy to see if there was no need for collaboration and dependency management there actually wouldn’t be need for the event itself – teams could just plan on their own.

The advantages of the Planning Event lie more in collaboration and dependency management than in the actual plan that results from the planning. This reflects the fact that if there weren’t dependencies between the teams, the event wouldn’t even be necessary. Some of the benefits of the Planning Event.

  • Creating clarity on what value will be realized over the planning period.
  • Creating clarity on what will be worked on during the time-frame covered by the planning period.
  • Discovering dependencies between teams and make agreements as to when they will be fulfilled.
  • Planning the work to be done in one or two week iterations to implicitly limit Work-in-Process.
  • Identifying risks and working on them.
  • Creating a sense of camaraderie among the participants.
  • Providing visibility to management of how the technology teams interact and creating an opportunity for them to create a better environment for their teams.
  • Providing visibility on how teams will move forward after the event.

Aligning around value realization

Before the Planning Event, it should already be clear what needs to be created for release and realization. If Product Managers are required to do this clarification during the event, it is a symptom of improper preparation. They do this by defining a sequenced list of Minimum Business Increments (MBIs).

In a nutshell, an MBI is the smallest increment of value that can be released that has realizable value. The notion of “release for realization” is critical for a plan that is focused just on releasing will not necessarily capture all of what is necessary in order for customers to realize the value of what was released. Far too often, items ancillary to technology are forgotten.

The focus should be on building MBIs as quickly as possible within the event.This results in a deliverable value graph that is constant and linear rather than looking like a “hockey stick” where value is realized at the end. To explore this a bit more,

Whether they are released or not is a business decision. But doing so lowers the risk of having nothing to release at the end of the program increment. You will be able to deliver value even if things don’t go according to plan.

When capacity is limited and conflicts arise between the MBIs, teams can decide which MBI to support based on the overall understanding the impact to overall Cost of Delay of their decisions.

Elements of an effective Planning Event

Planning Events don’t just happen. Here is what is required for an effective event.

  • Clarity on purpose of event
  • People in the event understanding what’s expected of them
  • A method for people to properly communicate with each other
    • Everyone can be together (great for the social aspects of the event)
    • Teams can be remote but communication channels have been defined for inter-team communication and intra-team communication (for more, see the section on Remote Events)
  • Someone experienced in leading events of this type
  • Proper preparation of the backlog
    • A sequenced list of what items of realizable value are to be worked on
    • A way to tie all program backlog items back to this list

Events should take place over two days even if only a half day is used each day. The reason for this is that it gives time for people to reflect on what happened and is needed. The subconscious mind will prompt new ideas overnight.

The following sections give more detail.

Preparing for the Planning Event

Proper preparation is crucial for an effective Planning Event. As said before, Product Managers must be clear about what needs to be created for release and realization and must have created a sequenced list of MBIs. The prioritization and sequencing should be based on WSJF on the MBIs. The items for the backlog should be appropriate for the amount of time of the PI the planning is for.

In addition, before the event, teams should have been able to identify most of their dependencies their work has on other teams.

Dependency management

Clearly dependency management is essential for an effective event. If there weren’t dependencies teams could just plan and deliver on their own. There are different types of dependencies, however.

Technical dependencies

These are dependencies where one feature or story won’t even work without another. For example, updating a customer record requires that somewhere a customer record can be created.

Business dependencies

These are dependencies where the system will function, but where a business rule in one part of the system requires functionality in another.  For example, a new type of client may be added but the controlling software is never given the functionality to take advantage of it even though it will run.

Dependencies outside of technology

These dependencies are often overlooked and a key reason MBIs are useful. These would include any marketing, shared services or DevOps requirements. The difference between releasable and realizable are often of these type. Releasing something without being able to support it or having marketing be aware of it cause clear challenges to realizing value.

Capacity

If there is not the capacity to complete an MBI because of limited capacity, it should be considered whether to do another MBI that can be done before it.

Making agreements regarding dependencies

When a dependency is identified, it is important that an agreement be made about when it will be met. In some companies one team just tells another they need it and by when. But notice that’s not an agreement. That’s a mere request disguised as a demand.  If later the team finishing the dependent story can’t get it done in time they will often just say they can’t do it. However, if it is made clear before the event that when one team needs another team to get something done, then both teams must agree to the date at which it will be done.

Having a visualization tool to help during your planning event that allows for deferring commitment can often be useful for shared services teams that several teams are depending upon. Such a tool can also help with avoiding having the program backboard becoming a bottleneck. Such a tool should be designed for events of this type so that entering information into them is easier than putting it up on the program board.

This is actual output from Net Objectives Program Board Builder tool that automatically builds the program board with little effort. Bold red borders indicates the backlog item is involved in an uncommitted dependency.  The lines are different colors and style to create easy visibility on what connects to what (the difference don’t represent anything. Note that manual boards can be built by just adding a sticker when an unagreed to dependency is present.

Running the event

How the event is run often depends upon the how the work being done relates to the teams. In very large companies, it may be that work for an MBI is spread amongst several teams. But in many companies whose technology is less than 1000 people, teams are already product oriented. In these cases, a team is often responsible for most of an MBI, where the event is being used to just manage the few stories each MBI may have dependencies on with other teams. In this case, each team can be responsible for their own commitments – the MBIs they are committing to as well as the stories that others are dependent upon.

The event is best run over two days, even if it can be squeezed into one day. This provides a little reflection time which is very valuable.

At the end of the event

A little time should be left at the end of an event to see if moving any stories around can shorten cycle time. Very often in an event certain stories are started earlier than they need to. A reflection of the program board can often reveal significant improvements here.

How to run events remotely

If your organization’s work is mostly organized around teams that build their own MBIs and only need other teams for a few dependencies, the event can be run remotely with a good planning tool. These are not the same as tools such as AgileCraft, Computer Associates, LeanKit, etc., which are about managing work during the program increment itself. A planning tool needs to be designed so that using it is easier than using a board. If you have a way of doing this, then teams can connect with each other in the following way:

  • Each team has a representative on a teleconference that has every team represented
  • Each team is in one location or all team members are on their own teleconference

This enables teams to work on their own stories while communicating with other teams that they are dependent upon or who depend on them.

Variations on Planning Events

Although the program increment planning event originated with SAFe you don’t have to do it as prescribed in SAFe. Sometimes a one-off planning event to get dependencies mapped out and then going to a flow model is best. Sometimes doing planning events every month is best. These two are often the cases for mid-scale organizations. Planning events should be done as frequently as possible as doing so enables

Summary: Achieving scale

Regardless of the approach you are taking, Planning Events should include the following:

  • Using Minimum Business Increments (MBIs) and MBI-thinking as the method to focus what work is to be done.
  • Creating visibility of MBIs, when they are to be released, and what they depend on
  • Making local decisions in the context of the bigger picture. In particular, when a team gets more requests than it can handle, determine priorities based on which MBI dependent upon them is more important
  • Managing Work-in-Process by breaking work up into small iterations.
  • Agreeing to realize business value quickly. Guide all decisions and risks based on achieving business agility.
  • Identifying risks throughout the process.

A challenge with SAFe is that Planning Events are not guided by MBIs. There is more focus on when features are to be completed than on the possibility for the customer to realize value. This results in features that have bigger scope than is needed; too often, considerations about the “minimum scope required” only surface when it looks like we may not complete the work in time.  By creating visibility of the MBIs and when they can be released, everyone can work together on getting value to customers or the business and not merely building functionality.

For companies with fewer than a thousand people in their technology group, the planning event integrated with good Agile Product Management can often be a better choice than a full implementation of SAFe or even SAFe Essentials.