Release deadlines are often fixed, imposed externally by such things as trade shows, accounting pressures, or contractual obligations. But since the goal is to get working software into the users’ hands as quickly as possible in order to make “course corrections” as soon as possible, every effort is made to keep release software development cycles as short as possible. Agile release cycles should certainly be kept shorter than a year, and are often as short as six months or three months. A release is, in turn, made up of iterations. For a given project, iteration length will typically be fixed at a length somewhere between a week and a month. If the release is in six months and iterations are going to be two weeks each, the release will consist of 13 iterations.
In some environments, software may be delivered to users, or at least a subset of users, incrementally at the end of each iteration or every couple of iterations. After an initial feature list has been identified, prioritized, and potentially estimated, the team holds a release planning meeting to establish the overall release schedule and determine which features can likely be delivered. The overall release plan in terms of prioritized features is then used to directly feed individual iteration plans.
Some agile methods stress clear separation of responsibilities between programmers and customers. During planning, only the customer is responsible for business decisions and prioritization and only the programmers are responsible for task estimation and development execution. Agile methods also strongly discourage management from capriciously imposing technology choices on the development group, instead giving developers as much latitude as possible to choose the best tools for the system and the project.
Preliminary release planning
The goal of initial release planning is to estimate roughly which features will be delivered by the release deadline (presuming the deadline is fixed), or to choose a rough delivery date for a given set of features (if scope is fixed). We use this information to decide whether or not the project will produce enough ROI to at least pay for itself, and therefore whether or not we should proceed.
Initial release planning meetings rarely last longer than a day – or two half-days if you just can’t stand to stay in a meeting for an entire day. First, the customer presents the prioritized features to be delivered. Ideally, the developers have already devised rough estimates of how much work is required to implement each of those features.
Using the developers’ estimates and the customer’s feature priorities, the team lays out a release plan, mapping features very roughly to the first few iterations. Developers may find that fairly low-priority features pose design or architectural risks, and may therefore ask customers to consider assigning them to earlier iterations anyway, in order to address those potential risks as early on in the project as possible.
It is enormously helpful if the development team’s velocity on a previous release is already known. In that case, if scope is fixed, you divide the total estimate for all required features by the team’s velocity to provide the approximate number of iterations required to deliver the functionality, and thus the deadline. If the deadline is fixed (as is typical), then you multiply velocity by the number of iterations to get an initial sense of how many features can be delivered. If the development team’s velocity is not known, then they must provide an estimate for it, and the release plan must be understood to be less precise for the first few iterations, until a reliable velocity number can be derived.
Preliminary release plan
The initial release plan rarely satisfies all parties – either not enough functionality will be delivered or too much time seems to be necessary to deliver the desired functionality. But in the agile world, the team looks these hard truths in the face, and develops a software development plan around them. No one believes in scope miracles that will satisfy everyone. Instead of practicing collective denial, the team uses real metrics and negotiation to make hard choices as close to the start of the project as possible.
Agile thought leaders agree that while it is possible to adjust scope, deadline, resources, and quality for a given project, the only variables that respond well to adjustment are deadline and scope. Extensive research has shown that larger teams tend to deliver lower quality systems more slowly, while smaller teams tend to deliver higher quality systems faster. It may indeed be necessary to add programmers to a team, but that is likely to slow the team down for at least awhile, not speed it up. Once we accept these findings, then we accept that in our release planning, we must adjust either the scope or the deadline to produce a release plan that is agreed to be workable by sponsors, customers, developers, managers, and other stakeholders. The fact that the team makes these hard choices up front reduces overall risk for the project. It increases the chances that the team will produce a feature set that returns stakeholder investment more than adequately by the deadline.
Planning the release continuously
The initial release plan is understood to be rough. It must be detailed enough only to get us started, by predicting that the project will deliver enough return on investment to more than pay for it. (If the initial release plan predicts ROI that is too low to justify the project, then we can cancel the project before we waste very much money.) In agile projects we plan continuously, and we correct our course as we go. One of the primary mechanisms for course correction is allowing the release plan to evolve in response to all kinds of feedback. It will take at least a couple of iterations for team velocity to settle down. Iterations will sometimes deliver less functionality than was planned for, and sometimes more. Features, architectural choices, design choices, or framework or technology choices might prove to be too risky or simply unworkable. The user interface might require revision. Staff might be lost or added. Feature priorities might change. All of these factors will help us revise and refine the release plan continuously. When each new iteration plan is published, so should a revised release plan that reflects the new reality.
Startup & wrapup
Many agile teams plan to deliver only a small amount of functionality in the first iteration (often called “iteration 0”), in order to explicitly allow for working out initial technical and logistical issues, and perhaps also stressing the architecture from end to end. This can be critical for teams that have little or no agile experience. For a team without a good velocity metric, this might mean that only at the end of the second or third iteration has the velocity become stable and reliable.
Some teams also schedule up to two iterations at project close for stabilization, system-wide integration and testing, bug fixing, and user documentation completion. In an ideal agile project this would not be required, but in the real world it depends on the specific agile practices the team follows, the organizational structure, the overall complexity of the system, the non-code deliverables expected of the team, the complexity of system deployment, and similar factors.
FAQs
Do I really need to use releases and a release plan?
Some teams can get by without agile planning at the release level. For example, an ASP may simply deliver software into production every iteration (i.e., every few weeks), thus every iteration effectively is a release and simple agile planning by iteration may suffice. If, on the other hand, some level of visibility is required by management at the software release management level (i.e., progress, status, change from initial software development plan, etc.), then release-level planning and management can be invaluable.
How big are releases?
Releases typically range between two and 12 months. For longer releases, it may make sense to break it down into several sub-releases.
How many iterations are in a release?
The number of iterations within a release is typically driven by the schedule. If a release is six months long, and iterations are two weeks, then 13 iterations should be scheduled for the release.
Who participates in release planning?
For smaller teams, it may make sense for the entire cross-functional team to participate for both input and accountability purposes. For larger teams and organizations, a subset of the team may be selected or elected to represent the team.
How long do release planning meetings last?
Release planning meetings typically last between four and eight hours.
How much work is done in preparation for a release planning meeting?
Generally, quite a bit of work has been done prior to a release planning meeting in terms of project approval, budgeting, vision, team identification, etc. With respect to functionality, the customer has likely spent time working with development to identify initial features, as well as potentially in breaking them down and providing initial, high-level estimates.
Does the release plan change during the release?
As more information is uncovered, functionality is delivered, more about the system is understood, business needs evolve, and priorities change, the overall make-up of the release will almost definitely change. Although anticipated, the evolution of software release management over time will need to be communicated to all appropriate stakeholders.
