Release Plan

A Release Plan is a medium term plan that defines a series of high level goals that delivery teams can “sprint” or “flow” towards.
Release plans join up the Portfolio/Programme views with Projects/Delivery Teams.

Each Release is typically defined iteratively in terms of scope as a subset of a Backlog. We recommend Releases are defined in terms of Integration Scenarios or Features, or other elements from a Scoping Diagram, with target levels of Done. The HSD model itself provides consistent standard Definitions of Done to bring them together. We recommend planning Releases in a visual form similar to the HSD Big and Small Pictures, using Milestones over time:

In larger organizations, resource management can be done based on Release plans at a Portfolio level. Resources can then be traded across pieces of work by incorporating feedback from Release progress into higher level plans as estimates are refined. Release progress is typically tracked using Release level workflow metrics. We recommend that Releases are at a maximum quarterly, preferably monthly or continuous.


Personal Builds will happen very frequently, at a developer’s discretion, and are not formally tracked. They may well fail and such failures are simply part of the local software development technical practices – they should not be reported. Developers using compiled languages will often build simply to check their syntax and run IDE based code analysis – maybe never actually running a personal build. Team Builds tend to follow successful Personal Builds when a developer pushes their changes or an integrator pulls them into an integration stream or automated build server (see Continuous Integration).

Personal Builds tend to happen at the “Developed” level of the Definitions of Done, whereas Team Builds tend to happen at high levels of integration and Definition of Done.

A build may apply to a component, system or system-of-systems and represents proof  that the code elements pass inspection and some limited quality assurance. In the case of non-compiled languages, a build may be harder to define, especially at a personal level, however since personal builds are not tracked or reported that tends not to be important. We recommend that a basic level of developer testing, unit testing and/or static analysis is done prior to promotion of changes to a team Build level, even for non-compiled languages.

We recommend that team builds are frequent, preferably daily or continuously (see Continuous Integration). ). A Build may not be a releasable version of a product or product family. The purpose of frequent builds is to ensure that the collective changes that make up software are in a working state (and haven’t introduced “regressions” or Problems). If the interval between working versions is short, then finding the cause of bugs is relatively easier (and can even be done by “binary bisection”) making defects easier to fix or simply discard rather than fix.

Personal Builds will typically not affect a Product version number, whereas a Team Build might affect the very last part of a version number (e.g. 2.3.67).

Builds are the smallest form of feedback cycle in Holistic Software Development and therefore the earliest opportunity to prove value, reduce risk, verify and validate the product at both Product and Product Family Level.

Technical Development practices such as Test Driven Development, Pair Programming and Mob Programming can even move the feedback, verification and validation into the code production activity prior to a Build although they are no replacement for actually running working software.


A Release is a version of a product which has met enough high-level requirements to deliver sufficient business value that the product could be adopted by the business and deployed operationally. This means that Releases must have a high level of Done, typically as far as “End 2 End Tested” and even into “Business Acceptance”. While a Build typically integrates a number of low-level requirements to a minimal level of Done, a Release delivers a number of high level requirements to a high level of Done. A Release delivers  Business Value.

A Release (via a Release Plan) is also the bridge between planning phases (and therefore often contractual phases) and high level requirements such as Integration Scenarios and Features, or sometimes other Scoping Diagram elements.

These plans and requirements come together, through product delivery and integration into a Release – an implemented version of a Product or Product Family. Since a Release as a planning construct defines a scope in terms of the requirements it also bridges planning with architectural achieving risk reduction through working software.

A Release is the physical realization of a significant milestonein a development lifecycle. Releases are the heart of any development endeavor and so the heart of the H-Model. We recommend focusing planning, process, architecture and adoption efforts on Releases.

A Release represents a significant achievement for the development team, however not every Release will be deployed operationally as Release cycles may be de-coupled from Adoption and Business Change cycles. However, Releases that are not deployed carry quality and validation risks, despite acceptance activities so we recommend that adoption and release cycles are kept reasonably in sync. The only way to actually mitigate risks is to use working software in real situations, testing can only indicate not prove quality.

Continuous Deployment practices involve every releasable version of a product being, often automatically, deployed operationally. Continuous Deployment can be difficult for business users to become comfortable with, as from their perspective, the product can change every time they use it, however if deployment is truly continuous then user facing changes are typically small and can be easier to adopt than a large set of changes requiring user retraining.

Importantly, Continuously Deployed products have their quality assured continuously, meaning feedback can be continuous and so are far more responsive to change.

Very early Releases may be focused on proving architectural approaches and may not be viable products from a customer perspective, however early architectural releases are significant achievements for any development and we strongly recommend their use in conjunction with a risk driven approach. Despite not being viable products they are important points for feedback and course correction. We recommend that any release, including these very early releases is requirements based and delivers at least one functional requirement to avoid architectural gold-plating becoming divergent from requirements.

Releases will typically affect the major numerical or named parts of a version number/label  (e.g. 2.3.67).

Releases are a critical point at which planning, requirements, architecture, testing, and customer validation come together enabling feedback cycles throughout the Software Development organization.

Release planning is commonly dysfunctional in complex software organizations, in part due to the duality inherent in the concept of a release. Holistic Software Development aligns the various concerns at Product and Product Family Release levels through Requirements, Architecture, Integration Streams, Reporting, Environments and Definitions of Done – all cohesive at horizontal layers of the Big Picture.

The idea of a Minimum Viable Product (or MVP) has recently become popular to describe “a version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort” – Eric Ries.

 Read more: Minimum Viable Product

Integration Streams combine the output of multiple developers, and/or from multiple contributing teams in a complicated or complex system. They also provide a staging mechanism for testing prior to promotion from “build” to “release” enabling progression through the levels of done. Integration Streams are typically implemented as “streams” or “branches” in version control tooling.