Agile Release Planning Is A Necessity
Thomas M. Cagley Jr.
Audio Version: SPaMCAST 183
It has been said of Release Planning that it is not needed and a waste of time by those who feel that release planning is a retreat from agile. Alternately, it has been called both a black art and a communication vehicle by those who recognize it as a need. Simply put, release planning is contentious. Why the consternation over something so simple? Part of the angst is a relic of the past and part is a flaw in basic human nature. The first part, memory of over planning, we all have seen in some project and program methods and the second flaw is one of basic human nature in that when something is said it tends to be remembered (a delivery date for example).
A software release can result from one or many iterations. A release plan is a tool that describes what is to be included in the next release or releases based on what the team and product owner knows at a specific point in time. The release plan represents a top-down view of what will be delivered and when it will be delivered. The process required to generate a release plan leverages the knowledge of the team’s (or the teams’) velocity and a sized and prioritized backlog.
Jim Highsmith, author of Agile Development Ecosystems wrote, “A big part of an organization becoming agile is finding the appropriate balance between anticipation and adaptation.” Anticipation can be formal, big up-front planning that is integral to strategic planning and accounting. The tension is immediately established between the need to know and the need to adapt because agile techniques feature continuous feedback as a tool to determine and communicate when a feature will be delivered or even when a project will complete. The problem created by not knowing precisely (not that it’s ever very precise) when something will be delivered is that the business needs to know or at least wants to know, and they tend to control project funding and, in a broader sense promotions. Saying that a feature or project will be delivered someday over the rainbow or just “trust me” is usually a career-limiting move.
Why should an agile project develop a release plan?
Release plans act as a planning and communication tool to combat over-optimism. As a planning tool, the release plan helps the team know if what they are being asked to deliver is possible in the timeframe they have been given or how long it will take to deliver what is on the backlog. While this might feel like a big upfront plan (a regression from agile), a release plan lacks the overbearing level of detail that leads to a false sense of precision that is typically found in a big upfront plan.
A release plan can also be used to project roughly when or whether enough value will be delivered to meet the ROI projections. ROI projections are part of a business case that forms the basis for the business deciding to begin most projects. The release plan is a reflection of what we know now and will continuously evolve which means the value delivered can be continuously evaluated.
I would suggest that a release plan provides information that is critical for product owners, CIOs and other stakeholders to anticipate the future of their business. Anticipating the future is something that every executive wants to be able to do; something their stakeholders require from them. This is a casual loop that we might not like, but one that will be slow to be unmade.
Finally, Mike Cohn’s agile planning onion calls out the need for release planning for the reasons we just discussed; it is also a simple tool to help teams within larger project know how the jigsaw puzzle that is a project will fit together in the end. Knowledge of the end of the journey helps teams know where they’re going which improves morale and motivation.
Creating a Release Plan
The construction and maintenance of a release plan requires three basic components: velocity, prioritized backlog and elbow grease. Velocity is the average number of units of work delivered per iteration, the average number of story points is a typical measure of velocity (productivity is a similar but much maligned metric). For example, if a team delivers 30, 40 and 50 story points in three iterations, their average velocity would be 40 story points. Velocity will be used to anticipate how much work will be delivered (approximately) in each iteration.
The second component is the backlog. The backlog is a compilation of the work the project anticipates to be delivered over some period of time. The elements of a backlog can represent more than a release or single project. I’ve worked with backlogs for both maintenance and new application development that were continuously developed, maintained and groomed. In all cases the backlog represents the product owner’s priorities and should be sized using the same metric that was used to create velocity.
The final ingredient is elbow grease which comes into play once you have calculated (or estimated early in a project) the team’s velocity and a prioritized and sized backlog has been established. When the components are ready the core agile team meets to establish the release plan. The process of layering iterations into the backlog based on velocity sets the “what will be delivered” within a discussion of when. The initial release schedule can be used to communicate the order in which features can likely be delivered. Once created, the overall release plan of prioritized features, epics and stories is fed directly into the iteration planning process.
The process of creating a release plan is rarely as smooth as dividing the features by the average velocity. Dependencies, risk mitigation strategies (do the hard stuff first) and the granularity of features must be accounted for when planning. I think of the process as a combination of basic math and building a mosaic. A release plan can’t be viewed as precision vision of the future. The release plan is approximate for many reasons; however, biggest reason is that the product owner can and probably will reprioritize the backlog over the life of the project. The release plan can be used to continually test whether the delivery date (or dates) is feasible based on the approach being taken. This is not an exact science, perhaps this why some think of release planning as a black art.
The initial release plan is understood to be a rough prediction. When initially created, it must be detailed enough only to get the project started by predicting that the project can be delivered, that it will deliver enough return on investment to more than pay for itself or that it will be able to deliver the functionality required within the currently known constraints. Trying to create a release plan that provides absolute precision is tantamount to trying to predict the course of the stock market in granular detail. In Agile projects we continuously plan and correct the course as we go, rather than believing we have the power of clairvoyance. One of the primary mechanisms for course correction is the release plan which will evolve in response to feedback. Feedback includes identification of new stories, stories that take more or less time or basic changes in business direction.
So what’s next? Remember the release plan is just a plan; it will change. It is not to be created once and forgotten. In order for a release plan to have value, it will require leaders to spend time grooming the backlog. Grooming includes breaking down and re-estimating larger stories and epics. Update assumptions about velocity at the end of every iteration and using that update to determine the impact on the release plan. I suggest that in each iteration review, the team should discuss with the product owner and other stakeholders whether the project is on course to deliver what they want and what can be done if the project is not meeting their goals. When the plan for any specific story changes (and it will), review the changes with the product owner. The release plan is a tool to show the impact of change.
A release plan is a tool. Can any project leader answer the question of whether a project is possible without being overly optimistic without a simple tool? Even when an answer can be logically framed, can it be proven? A release plan can be used to provide a visual frame of reference to indicate what is possible and how changes or additions to the backlog will affect the project. What is possible is a question that can only be answered in terms of now, what is possible based on what we know and can legitimately foresee. The problem is what can be foreseen is generally not a perfect forecast. A release plan created from a team’s average velocity and a prioritized and sized backlog is good start.