Untitled3Large Agile programs, with numerous teams that each have their own cadence and need coordinated releases, add a level of complexity to planning and communicating releases. Instead of focusing on communicating how stories roll up to a release, program-level release plans typically take a higher-level view, communicating the relationships between themes, epics, teams and releases. Shifting to a big picture view allows the release plan to be concise enough to be able to communicate direction and progress.

A Moderately Simple Example

The example above is built on a release plan I helped build several years ago.  Just part of a single year of the program is shown below.  The program was comprised of three sprint teams and a program manager. Each of the teams had a different sprint cadence.  The program was planning to release code to their customer base (internal and external customers) twice during the first year and then every five months afterwards. The five month release cadence was driven by a major, outside client’s need. Each team supported a separate area within the organization and were allowed to release code outside of the program-level releases if needed. The product owners (yes, owners . . . not my favorite idea) prioritized the goals and themes based on business need and perceived value.  Epics that supported those themes were then prioritized based on value and dependencies.  Epics that were perceived to be larger (this group had sized the under stories and summed the size of the stores) drawn as thicker bars or across more sprints (meaning the epic was planned to be completed over a number of sprints).

Note that the plan shown is not complete.  I have used this format as a template several times.  The plan helps everyone understand the program is progressing. In at least one version of the program release plan we have up a “You are here” marker to show the breadth of progress that has occurred and is yet to happen. Keeping the plan as simple as possible makes communicating progress easier and also helps team understand when functions and features are planned.  The program-level release plan does not negate the need for a team-level plan that reflects the planning needed for a more tactical team-level release plan.

For a moderately complex program release plan I have found it necessary to add two other tables.  The first defines the epics related to the theme. Themes are used to describe larger sets of related functions within an application and are used to provide a focus to the team.  Epics are large user stories that are broken down into more granular user stories which can be estimated and completed in a sprint (remember INVEST). Here’s an example using the beer logo glass collection application we have described before.  A development theme might be focused on maintaining the glass collection (maintain equates to adding, changing and deleting glasses). A short description of an epic in that theme might be “add logo glasses”. Examples of the type of tables are shown below:


When using the program release plan to brief stakeholders, it is expeditious to have an idea where their pet function will be addressed.

The goal of program-level release planning is to help the teams, product owner(s) and the organization to conceptualize the flow of how functionality will be delivered and then to communicate the plan.  As with any other Agile tool, a program release plan will evolve as everyone involved in the gathers project level experience and knowledge.