For mid to large-sized organizations, the Planning Event has become to “scale” what the iteration planning event 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. It is important to be clear that planning events are not essential if you are using a flow model and your teams are able to complete work quickly. But for many organizations the planning event is the central part of Agile at scale.
Disciplined Agile FLEX calls these events Business Increment Planning events since the focus should be on realizing business value through the release of MBIs.
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 ensuring we focus on 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 lies 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,
There are three reasons to focus the planning on MBIs:
- It results in delivering value sooner
- Teams are encouraged to work closer with each other to deliver MBIs sooner
- Delays are reduced which reduces waste.
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.
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.
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.
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.
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.
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.
Consider what the focus on MBIs does
Look at the picture above. Notice how the focus on delivering MBIs quickly implies moving them to the left. This results in the three reasons mentioned earlier – quicker value delivery, great team collaboration and smaller delays in workflow.
Note: If you are using SAFe it is highly recommended that you Use MBIs in the Planning event.
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.
Variations on Planning Events
Although the program increment planning event has been popularized by SAFe, it was created by Pete Behrens while he was working at Salesforce. 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.
It is important that planning events be guided by MBIs and not features. While completing features is good, delivering and realizing value from MBIs is better. In addition, without the focus on MBIs, features often 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.
- Release planning in seven minutes: Pareto vs Parkinsons (Video)
- Read Focus on finishing stories in the sprint and on finishing MBIs in the Program Increment
- Why Business Agility. Short video on why we are going after business agility and not technology agility.
- Minimum Business Increments. The way to focus on building only the most important value is sorely lacking in the Agile community. This short video will introduce you to the concept of the MBI.
- Using MBIs in SAFe. SAFe’s effectiveness can be greatly enhanced by using MBIs instead of epics. This short article explains why.