Base milestones on objective evaluation of working systems.

—SAFe Lean-Agile Principle #5

Milestones

Milestones mark specific progress points on the development timeline, and they can be invaluable in measuring and monitoring the product evolution and risk. In the past, many progress milestones were based on phase-gate activities. In SAFe, however, progress milestones are better indicated by the fixed cadence of Iterations and Program Increments (PIs).

Planning in SAFe often takes into account three different types of milestones:

PI milestones – These support the ability to objectively evaluate progress towards the technical or business hypothesis. These occur on the PI cadence.

Fixed-date milestones – Not everything, however, occurs on cadence. System building also relies on external events, third-party deliverables, and external constraints. These are often fixed-date milestones that are distinct from the development cadence.

Learning milestones – In addition, learning milestones help validate business opportunities and hypotheses.

When applied properly, each type of milestone can bring focus to the work, help provide effective governance, and enable better business outcomes.

Details

The development of today’s large systems requires substantial investment—an investment that can reach millions or even billions of dollars. Together, customers, Agile teams, and other stakeholders have a fiduciary responsibility to ensure that the investment in new Solutions will deliver the necessary economic benefit. Otherwise, there is no reason to make the investment. Clearly, active engagement of stakeholders is needed throughout the development process to help ensure the realization of the proposed economic benefit and not just rely on wishful thinking that all will be well at the end.

The Problem with Phase-Gate Milestones

To address this challenge, the industry has historically followed phase-gated (waterfall) development processes, whereby progress is measured—and control is exercised—via a series of specific progress Milestones. These milestones are historically document-based and follow the traditional, sequential process of discovery, requirements, design, implementation, test, and delivery.

But as Oosterwal notes in the “Lean Machine” [1], they don’t really work. Phase gates don’t measure real progress and thereby don’t mitigate risk. For example:

• Using documents as a proxy for solution progress creates a false sense of security for solution progress. They also drive various measures and metrics, such as work breakdown structures, earned value measures, and others, that may actually impede flow and real value delivery
• Centralizing requirements and design decisions in siloed functions that may not be integrally involved in building the solution
• Forcing too-early design decisions and “false-positive feasibility” [1]
• Assuming that a “point” solution exists, early in the cone of uncertainty, and that it can be built right the first time

The net effect of all the above is that phase-gate milestones have not always helped mitigate risks; instead, a point solution is picked far too early in the cone of uncertainty. Problems follow inevitably, as Figure 1 illustrates.

With this backdrop, it becomes clear that a different approach is needed, as is described below.

PI Milestones: Objective Evidence of Working Systems

SAFe provides a number of means to address the problems. In particular, Principle #4 – Build incrementally with fast, integrated learning cycles, especially when used in conjunction with set-based design, provides elements of the solution.

With this approach, the system is built in increments, each of which is an integration and knowledge point that demonstrates evidence of the solution’s viability. Further, these objective evaluations are performed regularly, on the PI cadence, which provides the discipline needed to ensure periodic availability and evaluation, as well as predetermined time boundaries that can be used to collapse the field of less desirable options. Each PI creates an objective measure of progress, as Figure 2 illustrates.

This is true for both Essential SAFe and Large Solution SAFe, where solution/system integration and validation happen. Of course, the nature and type of system being built determine what is actually measured at these critical integration points. But the system is measured, assessed, and evaluated frequently by the relevant stakeholders throughout development. Most important, changes can be made while there is still time to make them, as Figure 3 illustrates.

This provides the financial, technical, and fitness-for-purpose governance needed to ensure that the continuing investment will produce a commensurate return.

In SAFe, these are the most critical learning milestones that control solution development—so critical that they are simply assumed as credible and objective milestones. In other words, every PI is a learning milestone of a sort. But there are other milestones as well, as described in the sections that follow.

Other Learning Milestones

In addition to the PI, other learning milestones can be used to support the central goal of building a solution that satisfies customer needs and generates value for the business. It is critical that the value proposition behind a new solution, or a large initiative, is treated as a hypothesis that requires conceptualization and validation against actual market conditions. Translating a hypothesis into business demand is the science and art of Lean-Agile product management. It involves a great deal of intermediate organizational learning. Learning milestones can help. For example:

• Do the new product Capabilities have a market that is ready to pay for them?
• Do they solve the user problem for the users being targeted?
• Are the necessary nonfinancial accounting measures available to demonstrate real progress [2]?
• What revenue can the organization expect?
• Is there a viable business model to support the new product or capability?

These and many other business concerns formulate the basic hypothesis for any large initiative. Learning milestones provide the necessary means to understand the feasibility of the solution and frame the right set of capabilities. Testing a concept of a new capability with a focus group, building and releasing a minimum viable product (MVP), or validating Lean UX assumptions for a minimum marketable feature (MMF) are examples of learning milestones. Such milestones do not necessarily occur on PI boundaries and may require significant effort, not only on behalf of the product development organization but also on the part of other business functions in the enterprise, such as sales, marketing, operations, finance, etc.

Every learning milestone assumes that there is a certain degree of uncertainty that needs to be translated into knowledge and, ultimately, into business benefits for the organization. This requires set-based design thinking and the ability to pivot, if necessary, to a different concept of the solution.

Since the outcome of any learning milestone impacts the understanding of intent, milestones are planned incrementally, as Figure 4 suggests.

Other elements, including the solution Vision, Solution Intent, and the Economic Framework, also evolve with the learning.

But learning doesn’t stop even when new product capabilities hit the market and start to generate business benefits. Successful products experience multiple Design Thinking cycles over their natural market lifecycle. In a Lean Enterprise environment, learning is an integral part of the organization’s Learning Culture, even for mature products. Applying meaningful learning milestones can help.

Fixed-Date Milestones

Every Lean-Agile enterprise wants to operate with minimum constraints. In part, that’s where agility comes from. The real world, however, has different concerns, and fixed-date milestones are common in both traditional and Lean-Agile development. For example, fixed dates may arise from:

• Events such as trade shows, customer demos, user group meetings, preplanned product announcements, etc.
• Release dates that are controlled by other internal or external business concerns
• Contractually binding dates for delivery of value, intermediate milestones, payment, demonstrations, etc.
• Scheduling larger-scale integration issues including hardware, software, supplier integration, and anything else where a fixed date provides an appropriate forcing function to bring together assets and validate

There are many more examples. In Lean terms, fixed dates have a nonlinear cost of delay. That is, required system Features become a much higher priority as the date comes closer, as failure to meet the milestones has negative economic consequences. This is directly incorporated into Program and Solution Backlog prioritization via WSJF; the “time criticality” parameter gets higher as the fixed date gets closer, thereby increasing WSJF priorities for elements dependent on that date. In any case, any fixed-date milestones should be reflected in the relevant Agile Release Train (ART or Solution Train Roadmap, so all stakeholders can plan and act accordingly.

Other Milestones

In addition to the above, there are often other concerns required for the economic success of product development, such as filing patents, certifying the system, auditing certain regulatory requirements, and so on. In many instances these milestones influence content or priorities of work; they may even alter the development process itself. For example, the need to perform solution certification may increase the transaction cost of accepting a new Release into production and may drive teams to seek alternative ways of acquiring feedback before release. Again, any such milestones should appear on the relevant roadmap.

Planning and Executing Against Milestones

An understanding of what types of milestones are required to support value creation may originate from different sources. It may be communicated to portfolios from the enterprise, or identified during the analysis state in the Portfolio or Solution and Program Kanban systems, or even during the planning and road mapping process for solution trains and ARTs. Eventually, teams will have to create a specific plan of action during the PI planning process, build specific Stories in support of a milestone, reflect the milestone in their roadmaps and PI Objectives, understand and address dependencies with other teams and trains, and negotiate scope and time trade-offs with stakeholders.

Thereafter, execution of milestones happens incrementally. Progress is demonstrated every PI.

Measuring Success

Successful execution of milestones requires criteria for what “success” means, so there can be value in associating specific measures and metrics with milestones. For example, a milestone of “capturing X% market share” may require an understanding of revenue or usage indicators. A learning milestone of “a search engine being able to reliably identify persons’ names on a web page” could be supported by a limited percentage of false positives across the pages in the “gold collection” of web data. In any case, thoughtful measures make for more meaningful milestones.

Learn More

Last update: 10 February 2021