PMI Sites
Register
Disciplined Agile
Search

    Risk-Based Milestones

    The DA approach is to have consistent, risk-based (not artifact-based) milestones addressed by teams, as appropriate, so as to provide leadership with visibility and collaboration points into the teams that they oversee. This approach is based on two observations:

    1. We can have common governance across teams without enforcing a common process. A fundamental enabler of this is to adopt common, risk-based (not artifact-based) milestones across the life cycles. This is exactly what the DA team-based lifecycles do. These common milestones are depicted in Figure 1 and the risks summarized in Table 1 below. These milestones are applied consistently, where appropriate, across all of the DAD life cycles. This has the advantage of enabling teams to choose their way of working (WoW), including an appropriate life cycle, while enabling leadership to govern them in a consistent manner.
    2. Repeatable outcomes are far more important than repeatable processes. Our stakeholders want us to spend their investment wisely. They want us to produce, and evolve, solutions that meet their actual needs. They want these solutions quickly. They want solutions that enable them to compete effectively in the marketplace. These are the types of outcomes that stakeholders would like to have over and over (e.g., repeatedly), they really aren’t that concerned with the processes that we follow to do this.
    Inception Construction T ransition Development of a potentially consumable solution Continued viability (Several) ©Project Management Institute. All rights reserved.

    Figure 1. The DAD milestones (click to enlarge).

    Milestone

    Risk Addressed

    Stakeholder vision

    Do stakeholders agree with your strategy?

    Proven architecture

    Can you actually implement this?

    Continued viability

    Does the effort still make sense?

    Sufficient functionality

    Has the team produced (at least) a minimum business increment (MBI)?

    Production ready

    Will the solution work in production and are stakeholders ready to receive it?

    Delighted stakeholders

    Are stakeholders happy with the deployed solution?

    Table 1. The risks addressed by the life cycle milestones.

    Let’s explore these risk-based milestones in a bit more detail:

    • Stakeholder vision. The aim of the Inception phase is to spend a short, yet sufficient amount of time, typically a few days to a few weeks, to gain stakeholder agreement that the initiative makes sense and should continue into the Construction phase. By addressing each of the Inception goals, the delivery team will capture traditional project information related to initial scope, technology, schedule, budget, risks, and other information albeit in as simple a fashion as possible. This information is consolidated and presented to stakeholders as a vision statement as described by the Develop Common Vision process goal. The format of the vision and formality of review will vary according to your situation. A typical practice is to review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page regarding the project intent and delivery approach.
    • Proven architecture. Early risk mitigation is a part of any good engineering discipline. As the Prove Architecture Early process goal indicates, there are several strategies you may choose to adopt. The most effective of which is to build an end-to-end skeleton of working code that implements technically risky business requirements. A key responsibility of the architecture owner role is to identify potential implementation risks during the Inception phase. It is expected that these risks will have been reduced or eliminated by implementing related functionality somewhere between one and three iterations into the Construction phase. As a result of applying this approach, early iteration reviews/demos often show the ability of the solution to support nonfunctional requirements in addition to, or instead of, functional requirements. For this reason, it is important that architecture-savvy stakeholders are given the opportunity to participate in these milestone reviews.
    • Continued viability. An optional milestone to include in your release schedule is related to project viability. At certain times during a project, stakeholders may request a checkpoint to ensure that the team is working toward the vision agreed to at the end of Inception. Scheduling these milestones ensures that stakeholders are aware of key dates wherein they should get together with the team to assess the project status and agree to changes if necessary. These changes could include anything such as funding levels, team makeup, scope, risk assessment, or even potentially canceling the project. There could be several of these milestones on a long-running project. However, instead of having this milestone review, the real solution is to release into production more often—actual usage, or lack thereof, will provide a very clear indication of whether your solution is viable.
    • Sufficient functionality. While it is worthwhile pursuing a goal of a consumable solution (what Scrum calls a potentially shippable increment) at the end of each iteration, it is more common to require a number of iterations of Construction before the team has implemented enough functionality to deploy. While this is sometimes referred to as a minimal viable product (MVP), this not technically accurate as classically an MVP is meant to test the viability of a product rather than an indication of minimal deployable functionality. The more accurate term to compare to this milestone would be "minimum business increment (MBI)" or “minimal marketable release (MMR),”. An MBI will comprise one or more minimal marketable features (MMFs), and an MMF provides a positive outcome to the end users of our solution. An outcome may need to be implemented via several user stories. For example, searching for an item on an e-commerce system adds no value to an end user if they cannot also add the found items to their shopping cart. The sufficient functionality milestone is reached at the end of the Construction phase when an MBI is available, plus the cost of transitioning the release to stakeholders is justified. As an example, while an increment of a consumable solution may be available with every two-week iteration, it may take several weeks to deploy it in a high-compliance environment, so the cost of deployment may not be justified until a greater amount of functionality is completed.
    • Production ready. Once sufficient functionality has been developed and tested, transition-related activities such as data conversions, final acceptance testing, production, and support-related documentation normally need to be completed. Ideally, much of the work has been done continuously during Construction as part of completing each increment of functionality. At some point a decision needs to be made that the solution is ready for production, which is the purpose of this milestone. The project-based life cycles include a Transition phase where the Production Ready milestone is typically implemented as a review. The two continuous delivery life cycles, on the other hand, have a fully automated transition/release activity where this milestone is addressed programmatically—typically the solution must pass automated regression testing and the automated analysis tools must determine that the solution is of sufficient quality.
    • Delighted stakeholders. Governance bodies and other stakeholders obviously like to know when the initiative is officially over so that they can begin another release or direct funds elsewhere. The initiative doesn't end when the solution is deployed. With projects, there are often closeout activities such as training, deployment tuning, support handoffs, post-implementation reviews, or even warranty periods before the solution is considered completed. One of the principles of DA is Delight Customers which suggests that “satisfied” customers is setting the bar too low. The implication is that we need to verify whether we’ve delighted our stakeholders, typically through collection and analysis of appropriate metrics.

    February 2022