PMI Sites
Register
Disciplined Agile
Search

    Running Effective Planning Events

    For mid to large-sized organizations, the planning event has become to “scale” what the iteration planning event is to scrum. Planning events are a great way to increase collaboration while coordinating the work of your teams. Planning events are not required if you are using a flow model and your teams are able to complete work quickly. But for many organizations, the planning event is an important element of agile at scale.

    DA 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 that you must stick to. It is to increase collaboration, to discover dependencies, to create a baseline for working together, and to provide some degree of predictability to stakeholders.

    Here are 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 making agreements about 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. It goes beyond specifications for the development team; it must also include everything required for the customer to realize value such as training, communication, or DevOps.

    Planning should focus on completing MBIs as quickly as possible. Whether or not an MBI is released is a business decision but at least you will have the ability to deliver value even if things don’t go according to plan.

    Planning helps the team to make decisions about which MBIs to support in the case that capacity is limited. They will be able to understand the impact of their decisions on the overall cost of delay.

     

    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 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 program increment the planning is for.

     

    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.

    Even as they prepare for the event, teams should identify most of the dependencies their work has with other teams. There are several types of dependencies to consider.

    • Technical dependencies. 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. 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. Dependencies that go beyond technical specifications such as marketing, shared services, or DevOps requirements. The difference between releasable and realizable involves these additional factors and are too often overlooked.
    • Capacity. If there is not enough capacity to complete an MBI, consider working on another MBI that can be completed within the timeframe. 

    When a dependency is identified, it is important that an agreement be made about when it will be met. In some organizations 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.

    Using a visualization tool (such as shown in Figure 1) 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.

    Program Board

    Figure 1. Example of a board to visualize dependencies

    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 organizations, it may be that work for an MBI is spread amongst several teams. But in many organizations 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.

     

    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

    Mid-scale organizations may find these variations helpful.

    • Conducting a one-off planning event to map out dependencies and then going to a flow model.
    • Holding planning events more frequently, even every month.  

     

    Related Resources