6.1 EBM Framework Architecture & Strategic Loop
Key Takeaways
Evidence-Based Management (EBM) is Scrum.org's empirical approach for measuring delivered value and the organization's ability to deliver it; it is supporting context, not a listed PSM II focus area.
The EBM Goal Hierarchy aligns organizational energy across three distinct horizons: Strategic Goals (aspirational, uncertain North Stars), Intermediate Goals (measurable milestones with timeframes), and Immediate Tactical Goals (near-term Sprint Goals).
The EBM Experiment Loop—form a hypothesis, run the experiment, inspect the results, adapt goals or approach—is a variation on the Shewhart (PDCA) cycle.
Scrum events operationalize the EBM loop: Sprint Planning commits to an Immediate Tactical Goal, the Daily Scrum inspects tactical trajectory, the Sprint Review inspects empirical market outcomes, and the Retrospective adapts organizational capability.
Effective Scrum Masters coach leadership to abandon output-oriented feature roadmaps in favor of outcome-oriented empirical value loops, decoupling investment decisions from speculative long-term plans.
6.1 EBM Framework Architecture & Strategic Loop
Important
Scope note: Evidence-Based Management is not one of the focus areas Scrum.org lists for PSM II (it is a separate focus area tested by PAL-EBM). This chapter is supporting context: PSM II scenarios about metrics, value, and organizational change are easier when you know EBM's vocabulary.
Note
Evidence-Based Management (EBM) was collaboratively developed by Scrum.org, the Professional Scrum Trainer community, Ken Schwaber, and Christina Schwaber to address a widespread failure in Agile adoption: organizations become proficient at delivering software quickly (the "feature factory"), yet fail to deliver meaningful customer or business value. EBM provides the empirical compass required to navigate complexity and maximize outcome over output.
The Fundamental Shift: From Activity to Empirical Outcomes
Traditional management operates on the flawed assumption that software development is a predictable, linear process. In this defined paradigm, success is measured through activity- and output-based metrics: milestones met, Gantt-chart tasks completed, hours logged, lines of code written, and story points delivered. However, in Dave Snowden's Cynefin Complex domain, there is no direct, predictable correlation between the volume of features delivered and the realization of commercial or customer value. Building an extensive set of capabilities on time and under budget is economically catastrophic if those capabilities fail to solve customer problems or alter market behaviors.
Evidence-Based Management (EBM) replaces speculative governance with empirical process control applied to business strategy. Rather than asking "Did we build what we planned to build?", EBM asks:
- Are we delivering value to customers and the business today?
- What potential value remains uncaptured in the market?
- How rapidly can we deliver new value and test emerging hypotheses?
- How effectively can we innovate without being paralyzed by technical debt and operational drag?
By measuring real outcomes through verifiable evidence, leaders can steer organizations dynamically, shifting capital and organizational focus based on observed facts rather than executive intuition or political bargaining.
The EBM Goal Hierarchy: Navigating Uncertainty Across Horizons
To prevent teams from getting lost in daily tactical firefighting or executing disconnected feature requests, EBM structures organizational intent into three distinct, nested horizons of goals. This hierarchy bridges the gap between high-level executive vision and daily Sprint execution:
| EBM goal level | Nature | Example |
|---|---|---|
| Strategic Goal | Important, aspirational, long-term; the path is uncertain and emergent | "Achieve market leadership in frictionless digital lending" |
| Intermediate Goal | Measurable stepping stone whose achievement shows the organization is on the path; the path is still somewhat uncertain, but not completely unknown | "Achieve sub-5-minute loan pre-approval for 20,000 users" |
| Immediate Tactical Goal | The current focus of improvement efforts | "Integrate automated credit verification with a sub-1-second response" |
1. Strategic Goal
The Strategic Goal is an important, ambitious outcome that the organization wants to achieve, but where the path to reach it is uncertain. It represents the ultimate destination—the organizational "North Star." Because the environment is complex, leadership cannot know in advance the exact sequence of steps required to reach the Strategic Goal. Instead, the goal must be expressed in terms of outcomes and customer impacts rather than specific product deliverables or technical architectures.
- Characteristics: High uncertainty, aspirational horizon, outcome-focused, stable over extended periods unless market disruptions render it obsolete.
- Anti-Pattern: Formulating the Strategic Goal as a prescriptive delivery date (e.g., "Deliver Enterprise Release 4.0 by November 15").
2. Intermediate Goal
Because the Strategic Goal is distant and surrounded by uncertainty, organizations need concrete stepping stones. An Intermediate Goal is a measurable achievement along the path toward the Strategic Goal, characterized by a tangible timeframe. Achieving an Intermediate Goal confirms or denies critical hypotheses regarding market demand, user behavior, or technical viability.
- Characteristics: Moderate uncertainty, clear target outcomes, specific time horizon (typically one to several quarters), measurable progress markers.
- Strategic Value: Serves as the primary focus for product roadmaps and strategic portfolio reviews.
3. Immediate Tactical Goal
An Immediate Tactical Goal is a near-term, actionable objective that directly supports progress toward an Intermediate Goal. The EBM Guide does not equate it with any Scrum artifact, but for a Scrum Team an Immediate Tactical Goal often maps to a Sprint Goal or to the goal of a short series of Sprints. It is an objective that the Developers and Product Owner commit to exploring in the immediate iteration.
- Characteristics: Low horizon uncertainty, highly concrete, actionable within a single Sprint timebox, directly testable through the creation of a usable Increment.
- Alignment: If a proposed Sprint Goal does not directly advance the active Intermediate Goal, the Product Owner and Scrum Team must question whether the team's energy is being squandered on peripheral distractions.
The EBM Experimentation Loop: Hypothesize, Experiment, Inspect, Adapt
Traditional project governance relies on predictive variance tracking—comparing actual spend and delivery milestones against a static baseline. EBM fundamentally rejects this approach in favor of the Experimentation Loop. Progress toward any goal is achieved by executing small, controlled experiments that validate or invalidate hypotheses:
Form a hypothesis → Run the experiment → Inspect the results → Adapt goals or approach
The EBM Guide describes this Experiment Loop as a variation on the Shewhart (Plan-Do-Check-Act) cycle popularized by W. Edwards Deming.
Step 1: Hypothesize
Every initiative begins with an explicit hypothesis. A well-structured hypothesis articulates what the team intends to do, the outcome they expect to observe, and the specific Key Value Measures (KVMs) that will prove or disprove their assumption:
"We believe that introducing instant biometric authentication during mobile checkout will decrease cart abandonment by 15% and improve Customer Satisfaction (CSAT) by 8 points within 30 days of release."
Formulating explicit hypotheses forces organizations to define what success looks like before committing substantial capital to full-scale development.
Step 2: Experiment
The Scrum Team designs and executes the smallest viable experiment that can generate empirical data. In professional Scrum, the experiment is materialized as a Done, usable Increment of product. Running an experiment may involve releasing a minimal functional capability, deploying an A/B test to a subset of users, launching a prototype pilot, or instrumenting telemetry to observe user interaction.
Step 3: Inspect
Once the Increment is in the hands of real users, the organization inspects the empirical evidence. Teams collect quantitative telemetry (e.g., conversion rates, system latency, error frequencies) and qualitative feedback (e.g., user interviews, customer support trends). The crucial discipline of inspection is radical honesty: teams must evaluate the data as it actually is, without spinning metrics to satisfy executive expectations.
Step 4: Adapt
Based on the empirical findings, the Product Owner and organization decide on the next course of action:
- Persevere: The evidence supports the hypothesis; continue investing in this capability toward the Intermediate Goal.
- Pivot: The evidence disproves the hypothesis; change the approach, adjust the Product Backlog, and design a new experiment.
- Stop/Abandon: The evidence reveals that customer interest is negligible or the opportunity is economically unviable; decommission the initiative to stop burning capital.
- Adapt the Goal: The evidence reveals that the Intermediate Goal or even the Strategic Goal itself was based on invalid assumptions about the market; adapt the goal hierarchy accordingly.
Connecting EBM to Scrum Framework Events
EBM is not an abstract executive framework that operates in isolation from engineering teams. It integrates seamlessly with the standard events and accountabilities of Scrum, transforming mechanical agile ceremonies into high-leverage empirical feedback loops:
| Scrum Event | Traditional "Mechanical" Focus | EBM-Driven Empirical Focus |
|---|---|---|
| Sprint Planning | Velocity forecasting, pulling task tickets, estimating hours | Formulating an Immediate Tactical Goal (Sprint Goal) that tests an explicit hypothesis advancing the Intermediate Goal |
| Daily Scrum | Status reporting, answering three backward-looking questions | Inspecting daily progress toward the Immediate Tactical Goal and adapting the plan to validate the hypothesis |
| Sprint Review | Passive demonstration of features ("demo"), accepting user stories | Transparent inspection of working software alongside market telemetry and Key Value Measures with stakeholders to adapt the Product Backlog |
| Sprint Retrospective | Venting frustrations, minor process tweaks | Analyzing team capabilities, technical debt, and process constraints to systematically improve Time-to-Market (T2M) and Ability to Innovate (A2I) |
The Sprint Review as the Strategic Pivot Point
On the PSM II assessment, scenario questions frequently probe whether the Sprint Review has degenerated into a superficial demonstration of completed code. In an EBM-driven organization, the Sprint Review is a collaborative business working session. The Product Owner presents not only the newly created Increment, but also the empirical data gathered from previous releases:
- How did the last release impact our Current Value (e.g., Net Promoter Score, transaction completion rate)?
- Did our experimental features close the Customer Satisfaction Gap as hypothesized?
- Has competitor action or regulatory change shifted our Unrealized Value?
- What should be our next Intermediate or Tactical Goal based on this evidence?
By anchoring Sprint Reviews in evidence-based outcomes, the Scrum Team and stakeholders operate as true business partners, co-creating product direction under conditions of continuous market uncertainty.
A bank's leadership sets the long-term aim of becoming the easiest bank in the country for first-time home buyers. A product group then targets 'cut average mortgage pre-approval time from five days to one day for 20,000 applicants by year-end,' and a Scrum Team's current focus is 'let applicants upload income documents from their phones.' Using the EBM Guide's goal levels, how should these three goals be classified?
The long-term aim is a Strategic Goal, the pre-approval target is an Intermediate Goal, and the document-upload focus is an Immediate Tactical Goal.
The long-term aim is an Intermediate Goal because it has no deadline, the pre-approval target is a Strategic Goal because it is measurable, and the document upload is a Product Goal.
All three are Immediate Tactical Goals, because EBM only recognizes goals that a single Scrum Team can achieve within one Sprint and inspect at the next Sprint Review.
The long-term aim is the Product Goal, the pre-approval target is the Sprint Goal, and the document-upload focus is an item on the Definition of Done for the Increment.
For the past four Sprints, a Scrum Team has achieved 100% of its forecasted story points, completing every planned Product Backlog item on time. However, recent production telemetry reveals that daily active users have declined by 12% and customer satisfaction ratings have dropped significantly. During the Sprint Review, the Product Owner celebrates the team's high velocity and claims the product is a huge success. How should the Scrum Master intervene?
Congratulate the team publicly on their flawless velocity and avoid raising the satisfaction telemetry in front of executives.
Facilitate an empirical discussion showing that high output (velocity, completed items) is not customer value, so the attendees inspect market outcomes and adapt upcoming goals.
Instruct the Developers to immediately increase their story point estimates by 20% in the next Sprint Planning session to offset the decline in customer satisfaction.
Demand that the Product Owner cancel all future Sprints until the sales and marketing departments identify exactly which features will guarantee user growth.
A Scrum Team's Product Backlog contains hundreds of disjointed user stories requested by various department heads, ranging from cosmetic interface redesigns to minor administrative exports. During Sprint Planning, the team routinely struggles to define a coherent Sprint Goal, ending up with a fragmented list of unrelated tasks. How can the Scrum Master utilize EBM to help the Product Owner and team establish meaningful focus?
Mandate that the Developers work on tasks ordered strictly by the corporate seniority of the requesting department head, eliminating the need for a Sprint Goal.
Divide the Scrum Team into three specialized sub-teams so that each department's requests can be completed concurrently in every Sprint without the departments competing for the same capacity.
Coach the PO to set Intermediate Goals under the Strategic Goal and use them to order the backlog and shape focused Sprint Goals.
Assign the Scrum Master accountability for selecting the top ten backlog items each Sprint based on technical elegance and code maintainability.
Sections you finish are checked off in the contents.