There are many levels of estimation including budgeting, high-level estimation and task planning (detailed estimation).  We can link a more classic view of estimation to  the Agile planning onion popularized by Mike Cohn.   In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes at higher levels of estimation. As you get closer to the core of the planning onion the case for the #NoEstimates becomes more compelling.

03fig01.jpg (500×393)

Planning Onion


Budgeting is a strategic form of estimation that most corporate and governmental entities perform.  Budgeting relates to the strategy and portfolio layers of the planning onion.  #NoEstimates techniques doesn’t answer the central questions most organizations need to answer at this level which include:

1.     How much money should I allocate for software development, enhancements and maintenance?

2.     Which projects or products should we fund?

3.     Which projects will return the greatest amount of value?

Budgets are often educated guesses that provide some approximation of the size and cost of the work on the overall backlog. Budgeting provides the basis to allocate resources in environments where demand outstrips capacity. Other than in the most extreme form of #NoEstimate, which eschews all estimates, budgeting is almost always performed.

High-level estimation, performed in the product and release layers of the planning onion, is generally used to forecast when functionality will be available. Release plans and product road maps are types of forecasts that are used to convey when products and functions will be available. These types of estimates can easily be built if teams have a track record of delivering value on a regular basis. #NoEstimates can be applied at this level of planning and estimation by substituting the predictable completion of work items for developing effort estimates.  #NoEstimates at this level of planning can be used only IF  conditions that facilitate predictable delivery flow are met. Conditions include:

  1. Stable teams
  2. Adoption of an Agile mindset (at both the team and organizational levels)
  3. A backlog of well-groomed stories

Organizations that meet these criteria can answer the classic project/release questions of when, what and how much based on the predictable delivery rates of #NoEstimate teams (assuming some level of maturity – newly formed teams are never predictable). High level estimate is closer to the day-to-day operations of the team and connect budgeting to the lowest level of planning in the planning onion.

In the standard corporate environment, task-level estimation (typically performed at the iteration and daily planning layers of the onion) is an artifact of project management controls or partial adoptions of Agile concepts. Estimating tasks is often mandated in organizations that allocate individual teams to multiple projects at the same time. The effort estimates are used to enable the organization to allocate slices of time to projects. Stable Agile teams that are allowed to focus one project at a time and use #NoEstimate techniques have no reason to estimate effort at a task level due to their ability to consistently say what they will do and then deliver on their commitments. Ceasing task-level estimation and planning is the core change all proponents of #NoEstimates are suggesting.

A special estimation case that needs to be considered is that of commercial or contractual work. These arrangements are often represent lower trust relationships or projects that are perceived to be high risk. The legal contracts agreed upon by both parties often stipulate the answers to the what, when and how much question before the project starts. Due to the risk the contract creates both parties must do their best to predict/estimate the future before signing the agreement. Raja Bavani, Senior Director at Cognizant Technology Solutions suggested in a recent conversation, that he thought that, “#NoEstimates was a non-starter in a contractual environment due the financial risk both parties accept when signing a contract.”

Estimation is a form of planning, and planning is a considered an important competency in most business environments. Planning activities abound whether planning the corporate picnic to planning the acquisition and implementation of a new customer relationship management system. Most planning activities center on answering a few very basic questions. When with will “it” be done? How much will “it” cost? What is “it” that I will actually get? As an organization or team progresses through the planning onion, the need for effort and cost estimation lessens in most cases. #NoEstimation does not remove the need for all types of estimates. Most organizations will always need to estimate in order to budget. Organizations that have stable teams, adopted the Agile mindset and have a well-groomed backlog will be able to use predictable flow to forecast rather than effort and cost estimation. At a sprint or day-to-day level Agile teams that predictably deliver value can embrace the idea of #NoEstimate while answering the basic questions based what, when and how much based on performance.

Kitchen remodeling is an epic comprised of many stories.

Kitchen remodeling is an epic comprised of many stories.

A user story is a brief, simple requirement statement from the user perspective… sort of.  In the wild, user stories come in multiple sizes, can be grouped many ways, and can be used to represent more than just functional requirements.

User stories come in many sizes.  The term epic is often used as a label for large stories that will be broken down into smaller pieces. Conceptually an epic is group of closely related user stories that have not been explicitly realized. A rule of thumb for identify epics is that they generally can’t be completed by a single cross-functional team in a single sprint. As teams breakdown epics into user stories, typically, the story can be completed by the team within the sprint.  The level of granularity should be as small as possible (thin slices of usable functionality) in order to reduce the chances of a story creating a bottleneck. Mike Cohn (SPaMCAST 43 and 45) coined the acronym: INVEST to describe a user story. A user story is:

  • Independent: they stand alone
  • Negotiable: they are a conversation
  • Valuable: they deliver a benefit
  • Estimatable: the team can determine how long it will take to complete the story
  • Small: or sizeable, and
  • Testable: the story can be proved

Themes are a common mechanism to describe high-level objectives, products or sub-components of products. Themes can include many epics (or in extreme cases only one) and user stories, and may be implemented across multiple programs.  Themes act as a convenient mechanism to group functionality so that stakeholders at different levels of the organization (executive to developer) can conceptually understand what is being requested. As with any grouping, once a hierarchy is established someone with rush to identify steps along the continuum. Some tools and theorists talk about themes and sub-themes. An example one of the themes for developing an interview based podcast would be to prepare an interview for podcasting.  Stories and epics would be needed to schedule the interview, record the interview, edit the interview and package the interview for the podcast.

What can be described as user story?  Many proponents of the concept of user stories would suggest that stories can only be developed for functionality targeted only toward user, i.e. any person or “thing” that interacts with the software. Many pieces of work like issues, risks and infrastructure would be documented using a different mechanism.  However, the world has moved forward since the early days and now the discipline of the user story can and is many times applied to all types of work.  For example, a mature Agile organization I spend time with documents project and program risks as user stories and incorporates those stories into their backlog.

User stories are a means to an end.  They help stakeholders and Agile teams understand what needs to be accomplished.  Using the standard structure of a user story (persona, goal, benefit) to organize all of the pieces of work facilitates conversations. Grouping mechanisms like epics and themes help stakeholders at all levels understand the project and groups of functionality conceptually, which again facilitates conversation. More conversation leads to a greater probability of delivering what is needed and wanted.

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.

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.