Release Plan


Step out of the chaos!

Step out of the chaos!

Information technology projects are typically a bit chaotic due to interaction of people, the environment and the inherent complexity of software and hardware. The bigger the project, the more complex and chaotic the project becomes. Unfortunately, all products and services can’t be delivered based on the output of a single small team or even a swarm of independent small teams. Coordination and group thinking is required to deliver large projects. Scaled Agile Framework Enterprise (SAFe) addresses this coordination and planning need with a period release planning event. Release planning is one the lightning rods in the discussion of scaled Agile frameworks overall and SAFe in particular.

In SAFe, release planning is done as a large-scale event for each program increment (a period of time typically spanning 8 – 12 weeks). The goal of the of the two-day release planning event is not only to synchronize and energize everyone that is working on the project, but also to assure a coordinated approach to delivering value. A few of the critical success factors for this group planning and coordination activity are:

  1. Release planning is a formal meeting with an agenda and roles. Preparation must occur before participants begin showing up the first day of the meeting. Typically the program’s vision and linkage to the business objectives and the top priorities of the initial program/feature backlog are used as inputs into the event. The release train engineer (who facilitates the event) will need ensure that the workspace and tools the teams will use are prepared.
  2. All members of the program should participate in the release planning event. Release planning is both a planning and coordination event. In the release planning event, teams develop and coordinate their plans for the next set of sprints in an environment that actively encourages communication and sharing. Everyone involved in the program brings different skills and experiences to the table; therefore they can provide unique insights into how the program can deliver maximum value. For example, if a program based in the US was leveraging offshore developers in the Ukraine and testers in India would planning be as effective if team members in India and the Ukraine were excluded and just told the plan? How many challenges and issues would be exposed later in as functionality was delivered that could have been solved by upfront communication?
  3. Release planning events are best when done in person. Programs need to ensure that release planning events are scheduled and that budget is available. Budgets for the events should include travel both travel and logistics.   When travel is not possible, the program leadership should make every effort to make the communication as intimate as possible (in-person being the most intimate and then in descending order: video, audio, test chats and smoke signals). Remember that if it is difficult to hear and participate, participants will get bored and stop paying attention.

A classic advertisement during in 2009 Super Bowl showed a cowboys herding cats. Large projects might not be quite as chaotic as that, however if teams don’t have a clear vision or don’t understand the interactions and relationships between what they are delivering and what others are delivering chaos could ensue. The Agile release planning event in SAFe is a mechanism for solving the planning and communication conundrum.

Some rituals are better than others

Some rituals are better than others

Agile release planning is an important tool for Agile projects and programs. It is easy to elevate release planning to a formal Agile ritual, done at a particular time and in the same way. Like a ceremony. My observations of Agile teams suggests that the ritualization of release planning (and all the other Agile techniques, for that matter) reduces the team’s ability to tailor the process or to experiment with variations that better match the dynamic nature of Agile projects. To make sure you are staying as flexible and dynamic as necessary remember the following points:

  1. Release planning is iterative and incremental. Release planning is usually done during sprint planning and then over and over again as needed.  Change occurs incrementally and based on feedback gathered thought team performance and feedback from the team.
  2. Release planning should be adjusted to deliver value in the fastest possible manner. The product owner and the team should continually tune the release plan to deliver value as early in the project as possible.  The minimum viable product or the walking skeleton are tools to help identify and plan for the delivery of value early.  The delivery of value helps to generate feedback, customer satisfaction and team motivation.
  3. Keep it simple. Release planning does not have to be complicated. Project and program complexity and the amount of information the organization’s culture demand will drive the complexity of release plan. Make release planning only as complex as it needs to be (and even then try to simplify).
  4. Experiment. Try new techniques for release planning. As far as I know, there is no perfect process for release planning in every team and organization. That means that we should be looking for process improvements at every opportunity.  Perhaps you will discover the best method ever, but even if you don’t you have every opportunity to get better and better and better.
  5. Release early and often. Release as often as it makes sense. The quicker you can get feedback from functionality running in production the better. Also the early and often mantra helps the project’s stakeholders understand that the release plan is not the same empty promise that many non-Agile release plans represent.

Agile release planning is a dynamic, continuous process that will evolve incrementally based on actual performance and the shifting business landscape. Change in Agile are rarely represented by a big bang, the creation and evolution of an Agile release plan is no different.

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:

 Untitled4

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.

A simple Agile release plan

A simple Agile release plan

Agile release plans are powerful tools to communicate direction to the organization AND the team.  There is a natural tendency to think that power and complexity are directly related. In other words, a powerful tool must be complex and require a significant level of effort to develop and maintain however Agile release plans can be simple and easy to deploy. The complexity of a release plan is driven by two major factors: the complexity of the project and the level of process fluff required by the organization.

An Agile release plan for a single team can be as simple as a sheet of paper with sprints marked off.  The team would then list the stories in the appropriate.  In the case above, the team did not develop a release plan until just before the second iteration.  They used a simple process of matching a sized (with story points) and prioritized (value) backlog to iterations based on their velocity (the average amount of work they were completing per iteration).  The release plan was taped to the wall in their team room so it was available to the team every morning during stand up. Note that at the end of iteration one the team realized that story number 29 was an epic and broke it down for completion in the next iteration. The release plan that the team used was very simple, but it served as a planning platform for the team and as a tool to communicate their approach for delivering value. The long-term usability of this very simple model could be improved by writing the stories on sticky notes rather than on the paper so that changes to the  plan would not require crossing stories out or rewriting the plan as changes occur.

I observed a more complex approach to Agile release planning that addressed a two team, two release project.  The project was funded for six sprints. The product owner anticipated releasing functionality twice during the project. Both teams were responsible for delivering architectural stories and functional stories in a coordinated fashion. The stories for the project were drawn for a larger application backlog that both teams used.  The following picture is a representation of the solution the team used (they actually used brown butcher paper, painters tape, sticky notes and yarn).

Untitled2

The two teams opted for a simple graphical approach. The plan was placed on the wall of their team room where the entire team could see the chart. As the teams kicked off, they held a joint meeting with their product owner and built the initial plan.  The first plan was viewed as even more notional than normal, as neither of the teams had established their velocity. The plan was to be updated as part of the sprint planning process. An interesting touch that this team used was the inclusion of dependencies between stories, which were marked by yarn. These teams were still working on developing independent user stories, which is sometimes difficult.

There are lots of ways to generate an Agile release plan. The complexity of the project and the process needs of the organization will guide how teams address and communicate release plans. Agile release plans do not have to be the outputs of highly complex tools, represented by highly polished charts to communicate direction. Simplicity in release plans makes it easy for the team to create, maintain and use Agile release plans.

 

Climbing flight is a project, climbing them all is a program

Climbing flight is a project, climbing them all is a program.


Release planning generally focuses on the process needed to deliver functionality from projects. Projects are a central fixture of business, so it is easy to overlook program and portfolio release. Release planning for portfolios, programs and projects each has similarities and differences.

Project Level Release Plans: The project release plan describes what the team plans to deliver and when they intend to deliver.  These are a reflection of the team’s capability (reflected in the team’s velocity) and the product owner’s prioritization and strategy. An individual project’s release plan is very focused on the team’s ecosystem and generally has more a tactical orientation.  Project release plans are typically very granular, showing individual stories.

Program-Level Release Plans: Program release plans have to reflect a significantly larger number of moving parts than an individual project. The Project Management Institute (PMI) defines a program as a group of related projects, subprojects and program activities. Programs, because of their breadth, have more dependencies between projects and subprojects and will require more coordination, which impact both technical and business components. For example, earlier in my career I participated in a number of bank merger projects. Those projects were classic programs that included account conversions, application changes, signage/branding changes and business process changes. A change in the plan for one component could potentially cause a change in all of the rest of them. Also after a point the cutover date was nearly impossible to change. Developing a program release plan reflecting the needs and worries of a wide range of product owners is more than just assembling a view of all of the project release plans. Typically program-level release plans are less granular than project release plans showing the delivery of features and epics (collections of stories).

Portfolio-Level Release Plans: Portfolio management exists to help organizations maximize the impact of IT or project budget. In a perfect world, the portfolio of IT projects would be driven by the organization’s strategy and anticipated business value. Projects that are critical to business strategy and deliver the highest value would be prioritized, and then magically there would be capacity within the organization to tackle the project/program in the prioritized order. That magic is reflected in portfolio release plan. Portfolio release plans use inputs that include the organization’s strategy, estimates of business value and budgetary cost, the projected capacity AND technical capabilities to generate a plan that forecasts the evolution of the overall organization. A typical portfolio release plan will be at a high level showing product, programs and projects.

All three release plans are related. Project release plans influence program release plans and program release plans influence portfolio release plans. However, each release plan is not simply an aggregation from one level to the next. Project-level release plans are the most granular and are generally a reflection of the product owner’s needs and team performance.  Program-level release plans require negotiating the needs of multiple product owners, recognition of potential dependencies and reflect the performance of multiple teams. Portfolio release plans must integrate and balance organization level needs, capacities, capabilities and even politics. All three are important and having one does not lead linearly to the next.

For these wild dogs stalking their prey, the release plan is actually a catch plan.

For these wild dogs stalking their prey, the release plan is actually a catch plan.

In my essay Agile Release Plan: Strategic or Tactical?, I indicated that the release plan impacts the strategic direction and alignment of the business though the evolution of the organization’s software. I think that it would have been equally fair to suggest that the release plan is guided by the organization’s strategic plans. This describes a classic feedback loop. The organization’s plans guide capability development and capability affects the evolution of plans.  A release plan serves both tactical and strategic masters.

Tactically, the release plan dynamically answers the questions of what will be delivered in a release and/or when the release will be delivered. This helps the organization understand the value the team is delivering whether the team releases on a standard schedule or infrequently.  The plan is not only valuable as a communication vehicle, but it is also useful inside the team as a planning mechanism to help team maximize the value they can deliver.  The release plan allows the team (including the product owner) to layout the stories so focus the release’s impact.  An example of a tailored release plan: I recently observed a project that impacted three departments (one application was used by three departments).  A release plan was created with four separate releases. The product owner and the team clustered the functionality in each release so that it would primarily impact only a specific department in each release. Three release focused at the departmental work and a fourth was to be clean-up release.  The product owner want minimize the number of times each department needed to be retrained. The release plan was used both to plan and communicate the approach. the idea was to minimize the potential retraining in each department.

On a strategic level, the release plan provides a product owner with a tool to understand (and communicate) what the project has and is going to deliver to support their organization’s investment plan.  This is true whether the project impacts a product for an end customer or changes the software needed to support internal processes. As a Christopher Vedete recently put it: the release plan answers the “what’s the investment getting me?” Since the product owner owns the release plan, the cycle needs to match the strategic needs of the business. For example, if an organization was developing cloud software for personnel income tax processing, the organization would need to make the final release in conjunction with tax season. The release planning makes visible as much as is known about each release and then incorporates and shares that knowledge as new information is discovered. The release plan communicates direction and purpose.

The Agile release planning process steps away for the single sprint focus that Agile tends to have on a day-to-day basis and creates a wider view of the path the project is taking to meet its goal.  Short-term projects that run for a few sprints and then release and are done will not have to spend significant time developing and maintaining a release plan. However even a small project should spend some time to reflect on a path forward. Release planning for programs (a group of related projects) and for larger projects will invariably require more coordination as the need is greater because size is often directly related to strategic importance. Software projects that have strategic importance will always need an answer to the questions: 1) what are we delivering and 2) when are we delivering, so the organization can evaluate the impact those answers will have on the larger strategic plan.

Stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning.

Stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning.

In an Agile project, a release plan answers the “what and when”, based on organizational vision, project needs and team capabilities. The constituency of a release is usually broader than the Agile team. Classically, the interested parties would be called stakeholders. In order to develop a release plan that serves the organization, the team needs to understand the breadth of the release’s stakeholders. A potential list of stakeholders can be broken into three categories:

Obvious:

  • Agile Team
    • Scrum Master
    • Product Owner
    • Delivery Team
    • Business Users
    • Customer(s)
  • Marketing (for projects related to the products or the delivery of products)
  • Sales (for projects related to the products or the delivery of products)
  • Manufacturing (for projects related to the products or the delivery of products)

Program Level

  • Program Manager
  • Representatives from Other Agile Teams

Less obvious

  • Outside experts
  • Vendors/External Partners
  • Regulators

The majority of titles on this list are probably obvious; stakeholders that are directly affected by the release or will use the release’s functionality will need to be involved in release planning. A release plan for an Agile project within a program should involve a wider sample from other Agile teams. In order to determine who should be involved, you need to understand the relationship between the individual projects.  Those that are less obvious are rarely included in developing a release plan, even though these stakeholders can contribute significantly to the projects requirements.

One mechanism I use to develop the list of roles to engage in Agile release planning is to begin with the project’s walking skeleton.  The walking skeleton is generated from Agile Story Mapping and can be used to identify the minimum viable product. Once you outline the initial story map and walking skeleton, review each of the functions in the skeleton and ask yourself the following questions:

  1. Who will use this function?
  2. Who will develop and test this code?
  3. If this function interfaces to other applications (software and hardware), who owns the other application?
  4. Who impacts how the function must work?

This list of names are the people that could be involved in developing a release plan. Even if all of the folks on the list can not be involved, the list will provide a starting point. When deciding who to invite, make sure you identify the thought leaders on the list and representatives from interfacing applications.

La Sagrada Familia was a minimum viable product that is still being built

La Sagrada Familia was a minimum viable product that is still being built

An Agile Story Map combines three basic types of information: stories, workflow information and priority.  With the addition of velocity (i.e. how much work can be delivered), these three pieces of information provide the basis for release planning.  Release plans generally reflect one of two basic philosophies.  In the first philosophy, a release is based on the on a fixed amount of functionality. In the second, a fixed duration is used.  Let’s apply each these strategies.

Fixed Functionality Release

The first row underneath the marketable and architectural features, which contains the highest priority user stories, is called the “walking skeleton.” The walking skeleton represents a barebones version of the product or project. It should represent the lean concept of a minimum viable product; just the essentials.  If you were building a house, having a foundation would be a high priority unit of work and part of the minimum viable product. A finished basement playroom is not as high a priority, and not be part of the initial release or part of the minimum viable product.

One successful iterative strategy is for the walking skeleton to be the initial release.  Each subsequent release (or rows in our map) would flesh out the product. The process of iterative releases elicits feedback from real users to hone the backlog, so that subsequent releases will more closely reflect the user’s needs. Using the walking skeleton as a mechanism to trigger a release is a reflection of the functionality-driven release strategy.

Fixed Functionality Exhibit A

 Walking Skeleton and Fixed Functionality Release Boundaries

While the walking skeleton concept is most closely associated with new applications, it can also be applied to enhancement projects. In this case, the walking skeleton represents the minimum amount of new or changed functionality that would be useful to the customer.

Here are the steps to build the release plan:

Who: Whole team, lead by the Product Owner

  1. Identify the highest priorities required to satisfy the minimum viable product.  This becomes the walking skeleton and the first release.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
  2. Identify the next highest priority group of work items that form a coherent set of functionality.
  3. Repeat step two until all of the functionality in the map has been accounted for.

Remember that the Agile Story Map will evolve as the team builds a greater understanding of needs and receives feedback from stakeholders. Therefore, the release plan will change.

Fixed Duration Release

In the fixed duration release strategy, the team works as hard as possible for a specific duration and then releases the product. Release planning would be accomplished by applying the team’s velocity to a sized backlog. The release plan changes as velocity and the Story Map change.

Fixed Duration Exhibit

Walking Skeleton and Fixed Duration Release Boundaries

When developing a new application, this strategy only makes sense if the whole walking skeleton is released in the first release. As before, the walking skeleton represents the minimum viable product. The team would then work the highest priority work items, the user and architecture stories, and those completed in time would be packaged and released.

The main difference in process for building a fixed-duration release plan is the fixed date and packaging the work based on capacity (velocity or productivity):

Who: Whole team, lead by the Product Owner.

  1. Identify the highest priorities required to satisfy the minimum viable product.  This becomes the walking skeleton and the first release.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
    • If the duration is more than the implementation window, either work with the Product Owner to refine the walking skeleton, add additional Agile teams or redefine the fixed duration.
  2. Identify the next highest priority group of work items that form a coherent set of functionality.
    • Calculate the number of sprints required to deliver the release based on the team’s velocity or productivity.
  3. Repeat step two until all of the functionality in the map has been accounted for.

In both strategies the organization must weigh the business value of each release against the cost of development.  If the organization can make better use of the Agile team and other project resources, the work on the project should be halted and a new project begun.

The prioritization process in of Agile Story Mapping helps to identify a minimum viable product/walking skeleton.  Once a walking skeleton is identified Agile Story Maps provide a great platform for release planning. The mapping process supports both of the popular release strategies and methods that combine the two.  The visual nature of Story Mapping helps to ensure that the team and their stakeholders understand the impact of changes to the release plan as new stories are added or priorities are changed.

Feedback loops help make planning more effective.

Feedback loops help make planning more effective.

Agile planning is layered and continuous throughout the life span of a project. The continuous nature of Agile planning provides a stream of feedback that makes making course corrections more effective. Agile release planning actively uses feedback loops from sprint/iteration planning and indirectly from daily sprint meetings.

Mike Cohn described Agile planning as an onion with strategic planning on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer of the Agile onion includes planning, and that planning reacts to the performance of the layers below.  Release planning provides sprint planning with information about the goal(s) of upcoming releases and the functionality that the product owner and stakeholders are anticipating. Sprint planning further breaks the goals and needs into tasks and activities. The team translates results into knowledge and information that is used to refine daily activities and is then used to refine the next iteration of sprint planning which in turn provides feedback to the release planning process. Each planning activity is influenced by results from next layer of activity.

Short iterations provide the ability to plan and then gather results that will either validate the plan or generate the impetus to change the plan. Feedback loops are an important part of ensuring that we continually adjust plans so that we get it right.

Release plans are not menus.

Release plans are not menus.

Developing an Agile release plan can be relatively easy. In general there are only a few moving parts. The inputs into the release planning exercise are:

  • Prioritized and Sized Backlog – The backlog represents the work to be done including bugs, features, technical items and knowledge acquisition annotated. Each item on the backlog needs to be sized using a unit such as story points, t-shirt size or function points. The backlog is prioritized by the product owner based on value, dependencies and business requirements.
  • Team Velocity or Productivity – Velocity and productivity are measures that represent how much work is normally completed in a sprint by the team or teams involved in a project.
  • Release Strategy – Two macro release strategies are often considered. The first is a time-boxed approach (fixed amount of time) or a scope-boxed (fixed amount of scope). The strategy will be used to determine what will be included in the release.

Using a simple approach for release planning, the process begins with the prioritized and sized backlog. The product owner and team walk through the backlog counting off sprints using the velocity or productivity to determine what can be done. The whole team is usually involved in the creating the release plan; however the responsibility for the plan lies with the product owner. Based on the strategy selected the release will occur when a fixed number of sprints are completed (time-boxed) or when a fixed amount of features are completed (scope-boxed). At the end of every sprint the process will need to be revisited based on the results of the sprint, work items may have been completed, not completed or new items discovered. This is a simple approach to release planning; however even more complex, scaled-up methods follow the same basic steps. In many projects I have used these basic techniques with sticky notes and brown butcher paper as tools to record the process.

 

Next Page »