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
- dependency management
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.