“How much detail do we need for our release plan?”
This is an important question to ask at the beginning of a software development project, or in the case of a long-standing product team, before the development of a major release of a system.
The answer to this question will determine the amount of initial effort that we put into documenting our plan, as well as how much effort we will need to maintain the documented plan over time. From an agile point of view, we want to take advantage of planning, which is to think through critical issues in advance, but not take on the risks of overthinking or making commitments too early.
In short, agilists aim for just enough planning.
Know Your Context When Release Planning
A foundational principle for business agility is that context counts: different teams are in different situations and must adjust their approach accordingly if they are to be effective.
An interesting implication of this is that there are no “best practices.” Instead, all practices are contextual in nature. Any given practice has trade-offs: it works well in some situations and proves to be a bad idea in others.
To choose an effective way of working (WoW), you need to understand the trade-offs of the various techniques available to you, and then select the combination that works best for you given the situation that you face, and the skills and culture of the people involved. Recognizing this, the following release planning options are choices rather than prescriptions.
Figure 1. The Plan the Release process goal.
In Figure 1 you see the process goal diagram for how a team may plan the initial release of a software-based solution. Notice how a plan may address schedule/time, cost, value, staffing considerations or combinations thereof.
Related: How to Fund a Software Development Project
One of the decision points that you need to consider is how much detail you will capture in your plan if any at all. This is the focus of this article, as shown by the red rectangle.
You can see on the goal diagram that there are eight decision points that you need to consider when planning a release and that each of these decision points has options. When there is an arrow beside the list of options, we say that the options are ordered; when there is no arrow, they are unordered.
In the case of ordered options, we’ve been able to rank the relative effectiveness of the options, with the most effective options towards the top of the list and the least effective options towards the bottom. It is important to note that the rankings shown in Figure 1 are for software teams, although we suspect the rankings are likely to hold true for non-software teams too.
Options for Level of Detail in a Release Plan
I believe that there are four options for planning the release of a solution; although I recognize that there may be more and that you may be able to combine strategies. As you can see in Figure 1, there is an arrow beside the options list indicating that it’s ordered. From most effective to least effective, the options are:
- Rolling wave: The plan is continuously updated throughout the release, like a wave, with more detail for upcoming work, and less detail for work further out. A rolling wave plan starts out as a high-level plan, and details, as appropriate, are added just in time throughout the release.
- High-level: The release plan indicates major milestones, any phases, any iterations/sprints (if your team works that way) and any dependencies between them. It does not address the detailed work to be performed. Instead, it trusts the team to self-organize and do whatever is appropriate at the time.
- Detailed: The release plan contains significant details about the work to be done and may even assign that work to specific roles or people. Details are identified at the beginning of the release, during a period that agile and scrum teams often refer to as “Sprint 0”, Inception or Initiation. The details are typically updated over time as the work proceeds.
- None: The release plan is not documented at all. Planning may still occur, but the plan itself isn’t captured.
Comparing Your Release Planning Options
As pointed out earlier, there is no such thing as a “best practice,” instead every practice works well in some situations and not so well in others. Table 1 overviews the trade-offs associated with the release planning detail strategies described above.
Related: Free Project Plan Template
When you know the trade-offs associated with an option, you can make a better product management decision as to which approach is most suitable for the situation that you face. Better choices lead to better outcomes.
Table 1. Comparing each strategy for the level of detail in a plan.
| Funding Option | Advantages | Disadvantages |
| Rolling wave | ·Very effective in fluid environments, particularly when requirements are evolving rapidly or the team members are not yet fully known.
·Works well with rolling wave budgeting because it aligns continuous funding practices with continuous planning. ·Enables teams to produce honest timelines and budgets for their stakeholders. |
·Requires flexibility on the part of stakeholders, because it removes the (comforting) sense of false predictability in favor of providing them the ability to steer and guide the team to success. |
| High-level | ·Works well for experienced teams that don’t need lots of plan details.
·Useful for giving stakeholders a high-level forecast for what will be delivered over time and to identify dependencies with other teams. ·Provides some sense of “predictability” without taking on the costs of detailed planning. |
·May be uncomfortable for people seeking the false sense of security that comes with detailed plans. |
| Detailed | ·Only practical for trivial initiatives where the degree of uncertainty related to requirements and technology is low, and the schedule is actually predictable.
·Often justified by a need to be regulatory compliant, even though the regulations rarely require detailed up-front planning. |
·Provides a false sense of predictability to stakeholders when it is applied in situations where the requirements are varying (which is the vast majority of situations).
·Requires significant, and usually unnecessary, effort to maintain later in the life cycle as the situation evolves. ·Drives the morale of the team down. |
| None | ·Appropriate for simple, low-risk initiatives in a highly collaborative environment.
·No documentation overhead. |
·Does not provide transparency to stakeholders who are not actively collaborating with the team. |
Choice is Good when Release Planning
If you want to be effective then you must match your approach to the situation that you face. Because different teams face different situations one single approach will not fit all, and instead, you need to have choices that you understand and can apply appropriately.
More importantly, you need to be prepared to evolve your approach as your situation evolves. As this article shows, you have a range of choices for the level of detail for your release plan. Our recommendation is to do the best that you can in the situation that you face and to always try to learn and improve.
Whether you plan in detail or follow an agile framework and plan more loosely, leaving open room for iteration, you still need to plan. ProjectManager is a cloud-based project management software that gives you the flexibility to plan as you see fit. With kanban boards, Gantt charts and a real-time dashboard that provides up-to-date data once you set that plan in motion, you’re always aware of change and can react quickly. See for yourself by taking this free 30-day trial.
