Agile Release Planning - Aligning with Executive Management

Executive Summary:

For longer-term technology projects, a quarterly planning Kanban board will not only help with release planning, but is also a great way to align program management with executive management on releases, resource capacity planning, costing, and ongoing project status reporting.

Quarterly Planning Kanban Board. 

In a previous article, I discussed methods to break down your product epics and features that were understandable to both executive management and product stakeholders, along with how to use the SAFe weighted shortest job first (WSJF) method to prioritize these features. In this article, I'd like to discuss a clear and simple way to present your agile release plans to executive management.

As part of agile release planning, you will need to identify epics and features that will be implemented over longer periods of time.  It's said that a picture is worth a thousand words, but with the advent of many new agile tools,  too many pictures can sometimes be overwhelming and information can get buried, especially when trying to communicate plans to executive management. This often results in miscommunications and many long unnecessary status meetings. As a program and/or product manager, it's critical you find a communication approach for both you, your teams, and more importantly, you executive management, that clearly, and accurately, depicts your initiative's plan and status.

Let’s look at the previous initiative example I presented for integrating a cloud-based HR system into your existing environment to replace a legacy HR system.

A simplified set of phases of the project identified were as follows:

Integrate new cloud-based HR System

·                  Environment Setup

·                  Integrate vended application with existing legacy systems

·                  Migrate existing employee & contractor data into vended application

These phases are what I would call super-epics.

After further analysis we came up with the following sub-epics and features for the Integrate phase:

Here is an example of expanding the Employee Update epics within the Integrate phase into features.

(Super) Epic	Sub Epic	Feature	Team A	Team B	Team C	Vendor A
. . .
HR Cloud Integration	Employee Update	HR Cloud Core Data Update		X		X
HR Cloud Integration	Employee Update	Facilities Location Update	X	X		X
HR Cloud Integration	Employee Update	Telecom Update			X	X
. . .

Example Epic and Feature Analysis by Team.

Note that we are expressing our epics and features from a business standpoint and not from a technical standpoint. We know which systems are impacted by identifying which teams need to be involved to execute specific features.  So Team A might represent the Facilities system, Team B might represent the new HR system, Team C might represent the Telecom system, and Vendor A might represent the HR System's vendor.

If these were architectural epics, of course we would reference specific tools, systems etc., because from an enterprise architecture standpoint, these systems, tools, and middleware are their business. Make sense?

• From executive management’s standpoint, they are primarily interested in when the main project phases (super-epics) will be completed and how much it’s going to cost them.

• From a program manager’s standpoint, they are primarily interested in when the epics (super-epics and sub-epics) will be completed and are they on or over budget. 

Note that you can call these levels whatever you want, but the point is that what management likes to see is generally at a much higher level than what execution/implementation teams like to see, and that you just need to be conscious of this. Some tools like Jira Portfolio can help you align these differences.

Here's another way to think about it.

Keeping in-line with Dean Leffingwell’s scaled agile framework (SAFe) concepts of implementing interconnected Kanban and SCRUM boards to manage a company’s portfolio initiatives, programs, and associated projects, we get this hierarchy of epics, features and user stories where epics represent executive strategy, features represent program management, and stories represent the tactical execution of programs.

Image Source: adapted from http://versionone.com Enterprise Agile presentation. 

 To help align both program/product management and executive management for longer-term planning, and to ease management into concepts of lean and agile such as Kanban boards, epics, and features, I recommend starting off with a Kanban board based on quarters. 

Here’s the basic approach.

At its simplest, each column on the Kanban board represents one quarter and an epic is placed in the quarter that it is scheduled to be completed.  Within each epic you can include the features that are planned to be released within that epic. It’s up to you to define your definition of done for each item on the board, and everyone should be very clear about what this means. i.e. is it just user acceptance tested, or does it mean it’s been rolled out to the field.

You can include as many quarters as you want, but I’d recommend making no more than 6 – 8 quarters at a time. You can reuse previous quarters on the board about every 6 – 9 months.  This view shows only the current year, but you can include quarters from the previous year and next year as well.

Quarterly Planning Kanban Board. 

I encourage program management to maintain this as a physical board in a place where executive management will see it as well as the entire team.  For remote teams, you can also maintain this in tools like Jira and VersionOne, but just be sure that you incorporate a process to ensure this has constant visibility.

Note that an epic may appear in multiple quarters because features within an epic will likely be incorporated into different releases. You can further refine this board by using color post-its or indicators on the post-it, to indicate whether something is on-schedule, delayed, or has a major blocker, and/or you might consider adding traditional "To-Do", "In-Process", and "Done" Kanban columns within each quarter.

Additionally, horizontal columns can be used to indicate which team is primarily responsible for which feature. You might even indicate specific release trains on the timeline as well.

Quarterly Planning Kanban Board with Team Columns. 

And yes, it's not that much different than a traditional calendar, but it's familiarity and bridge into agile concepts is it's key benefit, not to mention it can easily be incorporated as a Kanban board in just about any agile tool.

Another valuable dimension that can be represented here are the points and/or hours for each feature as well as the total points or hours for the quarter and for each team over a period of time. This allows you to plan and identify team commitments, constraints, and availability, along with a rough idea of both team and quarterly estimated costs. After a quarter has completed, you might even show planned versus actual hours to help with the next period of planning.

Quarterly Planning Kanban Board with team and quarterly hourly totals.

Deciding what to include and how to manage the quarterly Kanban board is something that will evolve over time and will be determined by your project and organizational needs.

If you focus on information that maximizes the value provided to your management teams and minimizes the effort to manage the board itself and you will find that implementing a big visible quarterly Kanban board will help bridge the gap between executive management and program management and help reduce unnecessary project status meetings saving everyone's time.

I would greatly welcome your feedback and experiences regarding agile release planning and management.

Blog header Image Source: theflowcentre.com