go to The FLEX Patterns

Program Level Planning Patterns

There are many different ways to plan. The FLEX Planning Patterns Group provides many different options depending upon the organization’s needs.

Note: Many of the FLEX Patterns were not documented in the patterns format. They are presented as they are still useful as documented. Future updates will convert them to the patterns format.

The Purpose of the Planning Patterns

The purpose of each of the patterns in this group are:

• being a gating factor for new work
• clarifying business initiatives
• socialization
• dependency management
• collaboration

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.

Describing the basic contents of a Planning Pattern

Forces: Different organizations will have different issues to deal with in doing their planning. What’s present will determine which pattern to use.  Forces include:

• # of teams  involved
• extent of dependencies between teams
• how far the organization can plan based on knowing what’s needed
• the transaction cost of a release
• the maturity of the teams
• tools currently available
• quality of the intake processes (discovery and development)
• outside dependencies of which the organization has no controle

Social issues to deal with: People will have different attitudes about planning. Those new to Agile may feel more comfortable with longer plans. Those comfortable with Kanban may not even want to plan.

Coaching tips: Discuss the value of shorter cycles while emphasizing that “planning” is really about collaboration and alignment

See Planning, Collaboration and Dependency Management for more.

Different Planning Patterns

Program Increment Planning Event from SAFe

Because FLEX is modularized it can borrow from good practices of other approaches.  While there are several shortcomings of the SAFe Program Increment Planning Event, it can provide a reasonable foundation.  The biggest one is planning with MBIs instead of features as described in Planning, Collaboration and Dependency Management.

Going from Program Increment Planning to Iteration Planning

Starting with Program Increment Planning Event from SAFe and then shortening the increment each subsequent planning event is one way to move from 3 months increments to one iteration increment.

One time planning followed by flow

When many mostly independent teams are involved in planning it s often useful to do a large planning event with all of the team but then go to a flow model for work after this.

Product owners provide coordinated backlogs to multiple teams

This is a useful pattern when multiple teams are needed to build some functionality.

Dynamic Feature Teams

This is useful when a group of developers are usually aligned around functions they can build but sometimes a requirement needing people from multiple teams is needed.

Return to FLEX Patterns