The Purposes of a Planning Event
The planning event has several purposes. These include:
- visibility of what is needed and what will be done
- how work is allocated to the capacity available
- being a gating factor for new work to ensure we don’t overload
- clarifying business initiatives
- socialization
- dependency management
- collaboration
These are very useful activities. But it is important to realize that these should mostly be attended to on an ongoing basis. They should not have to be solved by having a planning event.
One of the best ways to avoid overloading teams is to ensure that they don’t work on more work than their capacity. The planning event is a method by which work is initiated. Teams should pull only what they believe they can complete during the program increment from the program backlogs. The contents of the program backlogs should be sequenced by MBIs. That is, any features in there should be in the same order as the sequence of MBIs from which they come from. This avoids the last minute de-scoping one sees in many planning events. In other words, there is no need to pull a feature only to discover you don’t have time to complete it. Remember that features have been made as small as they can be by only scoping out what is needed in the MBI.
Planning Events Need to Focus On Finishing MBIs
We use MBIs as the core of our planning event instead of epics or features because computing Weighted Shortest Job First (WSJF) on either epics or features does not provide an effective ordering. Epics are bigger than the actual work we will implement. Hence, doing WSJF on an epic doesn’t really make any sense since some (most?) of the epic will never be implemented. Rather an epic can be thought of being a container for the features we will be creating.
But features, by themselves, often provide no value. Features, even when having no technical dependencies on each other, often have business dependencies on each other. This means that features often do not represent any value in and of themselves – that several features are required to deliver value. When using features as the increment of value, teams often find they have to de-scope the features during the planning event to find the subset of the features that are needed in the time frame allowed. We have found it more useful to create MBIs from our epics and then do WSJF on them. Then, during the planning event, we already have the focus we need on the features to build. That is, we define our features within the context of the MBIs from which they spring. This makes de-scoping during the event unnecessary – we have in essence already done this. MBIs get us focused on both our target market and the minimum business increment we can deliver. A focus on business value is a powerful thing.
Different Kinds of Planning Events
When development organizations are large and not able to deliver to delivering software on a frequent basis, a full two-day planning event that decides what to work on for the next 2-3 months may make sense. But at small scale, doing this is far from Agile. This article describes different ways of running planning events. The following methods are one’s that we’ve seen work really well in the situations discussed. They are given in approximate order of being more desirable. The key is to try what appears to be best and then adjust as you learn.
For large, and even mid-scale organizations, planning events are often the only time people from different parts of the organization see each other. As Eisenhower said “planning is everything, the plans are nothing.” While a plan is produced, the real purpose of the event is more one of collaboration and dependency management. While large-scale organizations may find 3 month planning events much faster than what they were used to, mid-scale organizations typically should be planning only 1-4 sprints ahead. At small scale, planning should be for increments of only 1 to 2 iterations. And neither scale typically needs a two-week planning and innovation sprint.
At small to mid-scale it’s often advisable to have one planning event to get things kicked off and then use a flow model afterwards. In this case teams don’t plan together after the first PI Planning event but rather track dependencies on a Kanban board.
I. Making Teams Independent of Each other by Having Cross-Functional Teams
The ideal situation is to have teams be independent of each other and each be able to have their own backlog with no dependencies at all. The advantage of cross functional teams is that having them reduces delays and handoffs as software is being built. In this case each team will have its own product backlog and, if doing iterations, iteration backlog. Teams should communicate with each other when dependencies are found. This might happen during the planning process if Scrum is used, or any time backlogs are refined. See Cross-Functional Teams: Improving Communication Between People who Work Together for more.
Achieve Cross-Functional Teams to the Greatest Extent Possible. Cross functional teams are teams that have the capabilities of building the software they have committed to with no outside dependencies. This is fairly rare in development/IT organizations that have more than 30 people. The larger the technology group gets the more difficult this becomes. Having cross-functional teams makes teams both more creative as well as more efficient because of fewer hand-offs and common knowledge.
II. MBIs can be mostly done by one team
In this case each team likely already has their own product backlog (and iteration backlog if doing iterations) and it can be kept that way. If dependencies aren’t already mapped a planning event can be held to make them visible and get agreements between teams on how they will be handled.
If teams are doing Kanban there should be a cadence for validating plans for the next agreed upon time. If some teams are doing Scrum then the timeframe for their sprints should be the cadence. All teams should have their cadences aligned with each other.
Dependency management can either be done throughout the time between cadence points (e.g., sprints if using Scrum) or at the beginning of a timeframe/timebox. If done throughout the timeframe then the “planning event” may be more of a validation that dependencies have been made visible and a plan for meeting them has been agreed to.
III. MBIs are usually small and can be done by one team but sometimes require multiple teams to work on them
If teams are specialized and it’s either not financially advisable or desirable to the team members to have stable, cross-functional teams, a good solution here is have a backlog of large items in addition to each team having its own backlog of things it can do on its own. In this case, the big items are pulled first by a group of team members that can finish an item on the big backlog. As many of these are pulled as capacity is available. At that point any unassigned team members can pull items from their own backlog. When a multi-team piece is finished, the next one should be pulled if the dynamic team just created can do it. This may require stopping someone who is working by themselves on a small item to join the team. This technique can work well for either teams doing Kanban or Scrum. See Dynamic Feature Teams for more detail.
Dynamic Feature Teams: Creating Small Mobs Within a Large Group (Case Study). This article describes a case when the team’s demand for expertise bumps up against the needs of the feature team to handle the complex “Big Rocks” in the portfolio. It is a case when cross-functional teams are simply not possible or feasible. Guided by Lean-Agile thinking, one solution is to use a dynamic feature team.
IV. MBIs require more than one team to build
This can be managed in one of two ways mostly depending upon whether teams are doing Kanban or Scrum. In both cases there should be a common product backlog of MBIs that teams pull from. This backlog should be refined so that MBIs are broken up into small vertical slices which can be validated quickly. These slices can be further sub-divided into parts that will be pulled from individual teams. See Aligning multiple teams with Lean-Agile thinking for more
Aligning Multiple Teams with Lean-Agile Thinking. Three key principles of Lean Thinking for software development. This article describes how they apply to the value stream (the name Lean gives the workflow from “concept” to “realization of value”). It also describes three disciplines Lean-Agile teams will need to follow to keep value flowing. Finally, it illustrates how Lean Thinking guides Agile enterprises in addressing challenges in their context. Lean-Agile lays out a different, more disciplined approach for scaling Agile. (Al Shalloway. 11/2016)
See Running Effective Planning Events to give more information about the opportunity they represent.