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 desireable. The key is to try what appears to be best and then adjust as you learn.
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.
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.
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.
See Running Effective Planning Events to give more information about the opportunity they represent.