A Milestone is a significant event or decision point in the lifetime of a project.

Holistic Software Development uses a standard set of layered Milestones to drive the Risk-Driven Lifecycle. Milestones are a useful way of tracking top-level guesses about when scope will be delivered. Like estimates, they should not be treated as deadlines.

Milestones are often used to represent the completion of a key deliverable or completion of a significant stage of a portfolio, programme, project or other delivery method so that lower level deliverables and/or time periods do not need to be tracked. This means that milestones must be based on some lower level of evidence – not simply the date they were originally planned for.
A common dysfunction in many organizations that track milestones is that a lot of business pressure is applied to managers and teams to meet them. Milestone variance is seen as a bad thing, because it means planning is unstable. This dysfunction often results in almost all “planning milestones” hit on date but much of the original planned scope or level of quality missing. This is effectively “clock watching” and a measurement driven behavior that is actually damaging to a business as it devalues the feedback process. Planning is unstable by its nature, and estimates are uncertain.
Milestones will change and move, forcing them not to is dysfunctional.

To counter this common issue, we define a Milestone in three ways:

  • A planned date – defined as a date with a variation tolerance either way (e.g. 30/11/2034 +/- 4 weeks). We recommend that Milestones are set at month ends rather than specific dates to avoid false implications of accuracy unless there is a valid specific business reason to do so
  • A planned scope – defined in terms of requirements at a target level of done
  • A planned level of quality – defined in terms of acceptance criteria or quality confidence

As with all estimates we recommend always presenting Milestones with an indication of Uncertainty.

In Holistic Software Development we use a standard simple milestone pattern repeated at each level of the business:

  1. Scoped – the planned scope is a set of requirements that are understood at an inch-deep mile wide level
  2. De-Risked – enough of the solution has been successfully implemented to reduce remaining risks to an acceptable level
  3. Delivered – the planned scope has now been delivered
Scoped” Milestones will typically result in a set of Requirements at a scoped (not fully elaborated) state and architectural prototypes\spikes indicating feasibility (except for portfolios).
“De-Risked” Milestones will typically result in a Release as will “Delivered” Milestone(s).
“Delivered” Milestones are often split into a number of scope based Milestones representing key functional requirements or Integration Scenarios as incremental deliveries.
In HSD diagrams this full lifecycle is typically truncated for brevity however a product lifecycle plan might have a lot more detail:
This pattern of milestones means that any milestone, other than the “Scoped” milestones can be easily defined as an aggregate of contributing activity. Although in the example above we’ve represented two Product Delivery projects being in the context of a single Programme, real portfolios are rarely so simple. A real Portfolio is likely to be made up of numerous Programmes and stand-alone Projects as well as various other delivery methods. However, regardless of shape, each can trace its Scoped, De-Risked and Delivery milestones to the portfolio.
Here’s a visualized example of a real client’s portfolio:

Not all Programme and Project level “De-Risked” milestones will automatically trace to the Portfolio being De-Risked as different Programmes and Projects will have different risk profiles. Typically, maintenance projects are very low risk and may not even have a De-Risked milestone.

This dependency tree between milestones is sometimes called a “Portfolio/Programme Build Logic”. Since Holistic Software Development includes both programme and project management as well as technical practices which define Build quite specifically, we avoid the term “Portfolio/Programme Build Logic”. Software Product Builds are the primary unit of delivery, progress and business value – since the portfolio milestone dependency is simply a planning construct it is inappropriate to use the word “build” in this context.

We strongly recommend that Milestone dependencies are kept as limited and simple as possible since they will move and change as the solutions are elaborated. Since we know that they are indicative planning constructs early in the lifecycle there is no need to spend a large amount of time planning them and then re-planning them to give a false sense of predictability when we know that uncertainty is an unavoidable part of software engineering.

As mentioned in Risk Driven Lifecycle, Holistic Software Development is inherently risk focused. Milestones are defined in terms of risk reduction and points along the cone of uncertainty, which indicates, but does not guarantee, accuracy of estimates over time.

“Scoped” milestones exist to try and understand the shape and direction of work, outlining what needs to be understood, not that everything has been understood. De-Risked milestones are set at the point at which the business can commit to future investment along the cone of uncertainty with “reasonable” confidence.

Portfolio Milestones

If an explicit portfolio is maintained the following milestones can be used:Portfolio Scoped

The Portfolio is considered Scoped after the Portfolio Build/Selection process has completed. This results in a number of Portfolio Requests and associated Business Case Options that have been selected for execution by the business combining both new investments and Business As Usual, including maintenance projects and Operations requirements. This set of Portfolio Requests can be thought of and represented as a top-level Portfolio Backlog.

A Portfolio can only be meaningfully scoped in context of an Enterprise Architecture since this will impose certain technology choices and options, or indicate a direction for new development to take (e.g. SOA, Data Freedom etc.). Often the portfolio will result in changes to the Enterprise Architecture leading to dependencies between Portfolio items – we recommend minimizing these as much as possible.

Organizations that do not have meaningful executable architecture struggle to scope their portfolios.

Investment De-Risked
The Portfolio is considered De-Risked when enough top-level risk has been mitigated by constituent deliveries that continued spending is justified and secured for the rest of the Portfolio cycle (normally a year). Various Operations and Business risks may play into this Milestone as well as Programme and Project deliveries such as resource management risks, external competitive, business change, actor risks, technology risks etc.
Early Programme and Project deliveries that produce Product Releases mitigating technical risk through working architecture will reduce delivery risk substantially and so the Portfolio can be considered De-Risked when key (not all) constituent project (and if they exist programme) milestones Product De-Risked and Product Family De-Risked have been passed.
Change is inevitable, and in year changes to projects as further information is understood are inevitable. Few organizations start a year with an empty portfolio, there is frequently ongoing work from previous years. To deal with this ongoing situation we recommend Continuous Investment Review to balance risks with investment in response to change.
Incremental Business Benefit Delivered

The Portfolio can incrementally deliver Business Benefit as its various pieces of work begin to deliver Releases for Adoption and Business Change delivering Business Value. This Milestone might be split into multiple milestones representing major Product or Product Family deliveries, and/or related Business Change Milestones.

Key (not all) delivery Milestones will trace to the Portfolio Delivery Milestones.

Programme Milestones (only if programmes exist)

If using the Big Picture of HSD, and if programmes exist to co-ordinate constituent projects towards delivering Business Value from systems-of-systems, the following milestones can be used:

Product Family Scoped

A Product Family or Programme is considered Scoped when its requirements are understood at an “inch-deep, mile-wide” level. Often represented in terms of a set of Features and Integration Scenarios along with associated Non-Functional Requirements which collectively form the Programme Backlog. Supporting material such as User Experience Storyboards may also be introduced to further elaborate important parts of the high level requirements.

A Solution Architecture will be elaborated to a minimal level describing the structure of the proposed solution in terms of key components, services and products and their responsibilities (often in terms of simplistic APIs). The behavior of the Solution Architecture is normally represented as Solution Mechanisms and Integration Scenarios.

Product Family De-Risked

A Product Family or Programme can be considered De-Risked when its constituent Projects have met their De-Risked milestones or Project Deliveries have resulted in significant Programme risks being mitigated. This milestone will equate to a set of requirements from the Programme Backlog being completed to at least the “Product Family Integration Tested” Definition of Done, although we recommend that “Product Family User Acceptance Testing” is used to further de-risk the Product Family. If the Product Customer (or Product Forum) is not involved at this point there remains a risk that the Programme will not deliver the right set of properly integrated products to deliver Business Value.

Product Family Delivery

As with the Portfolio Delivery Milestones, the Product Family Delivery Milestone may be split into a number of incremental deliveries adding to the completed requirements set in a number of high level time-periods of Programme level Releases. These Milestones represent cohesive subsets of the Product Family requirements being ready in the form of Releases for Adoption and Business Change activities so Business Value can be generated.

Remaining requirements, if significant, may be put forward for a next lifecycle of the product as a Portfolio Request. Or, if less significant, into long-term maintenance and support, also represented as a Portfolio Request or a simple Change Request on a Product.

Delivery Milestones

Delivery milestones may be met in different ways by different delivery methods. Some delivery methods will not explicitly recognize Delivery milestones.

Product Scoped

A Product is considered Scoped when its primary requirements are understood enough to begin detailed elaboration and development. Often taking the form of a set of Scoping Requirements (User Experience Design, Integration Scenarios or Scope Models) elaborated as a set of User Stories (or borrowing a subset of a Programme Backlog). Requirements must be at a minimal level of detail required to understand likely schedule and form a candidate System Architecture in the context of Solution and Enterprise Architectures. Collectively this set of requirements forms the early Product Backlog. Be careful to avoid excessive detailing of requirement as detail is likely to change.

Product De-Risked

A Product is considered De-Risked when its primary risks have been mitigated through delivery of a set of requirements, in the form of working software, on a proven System Architecture to at least the “Integration Tested” level of Done although we recommend using the “Product User Acceptance level” of Done to further de-risk the Product. If the Product Customer isn’t involved in validation at this point there remains a risk that the wrong product is being built.

Product Delivery

The Product Delivery Milestone may be split into a number of incremental deliveries adding to the completed requirements set in a number of high level time-periods or Product level Releases. These Milestones represent cohesive subsets of the Product requirements being ready in the form of Releases for Adoption and Business Change activities so Business Value can be generated.

Remaining requirements, if significant, may be put forward for a next lifecycle of the product as a Portfolio Request or, if less significant, into long-term maintenance and support, also represented as a Portfolio Request or a simple Change Request on a Product.

Maintenance/BAU Projects

“Business As Usual” or maintenance projects are unlikely to have the same necessity to create cohesive understandings of scope in the form of backlogs and release plans and so the Scoped and De-Risked Milestones typically are not used in these projects. Instead a simple number of low-impact delivery milestones are used, roughly aligned to calendar periods or continuously. If at all possible, maintenance should take the form of Continuous Delivery, including Continuous Deployment rather than batching changes into calendar form.

If a maintenance project has enough new scope to require significant architectural effort, significant risk reduction and release planning then it is not really a maintenance project, it is a “new delivery” lifecycle of a Product or Product Family and should be treated as such. Hiding new development as maintenance is typically a dysfunctional measurement driven behavior caused by rigid financial governance. Holistic Software Development incorporates a distinction at Portfolio Request level between “New Investments” and “Business as Usual”, reviewed during the Portfolio Selection process, to help prevent this dysfunction.

In many organizations the term “Business As Usual” or BAU is used to describe work that is considered necessary for the business to function, including maintenance of legacy systems, infrastructure (see Operations). We recommend qualifying the business value of these BAU items on an annual basis to ensure that continued funding is producing Business Value as part of Continuous Governance. BAU can sometimes become part of the fixed cost base of an organization which means there is less funding for creating new Business Value and research/innovation. In turn this means less profit for commercial organizations and less delivery capability for non-commercial organizations.


Milestones are typically created and communicated as part of Planning activities.

Planning is the process of defining an intention for, and making arrangements for, achieving something of Business Value

In Holistic Software Development a plan may be a formal or informal description of how work will be done and controlled, defining scope, schedule and resource usage targets. We focus plans on achieving business value to ensure that plans are aligned to the business strategy and “doing the right thing”. Planning does not constitute progress, only working products should be considered progress.
Plans should be understood to be “best guesses” rather than accurate predictions of the future.
“No plan survives contact with the enemy.”
The purpose of a plan is to answer:
  • What is the work?
  • Where are we now?
  • When will the work be done?
  • What resources will be used?