7.3 Feedback Loops & Minimum Viable Product

7.3 Feedback Loops & Minimum Viable Product

In traditional waterfall projects, customer feedback is dangerously delayed until final user acceptance testing (UAT) at the end of the project lifecycle. If market assumptions were wrong, millions of dollars and months of effort are lost.

Agile frameworks eliminate this risk by instituting short, continuous feedback loops. By shipping small increments of software into the hands of real users early and often, agile teams substitute subjective management opinions with empirical, data-driven customer validation.

---

Product Increments: MVP vs. MMF vs. MMR

The terms MVP, MMF, and MMR are frequently referenced on the PMI-ACP exam, but they serve distinct operational purposes across product evolution:

---

The Build-Measure-Learn Feedback Loop

At the heart of agile product development is Eric Ries' Build-Measure-Learn feedback loop.

1. Build Phase

Transform hypotheses into an MVP or small feature increment as quickly as possible. The goal is speed to market, avoiding over-engineering features that users may not want.

2. Measure Phase

Expose the increment to real users and collect empirical quantitative data using actionable metrics (e.g., retention rates, conversion percentages, task completion speed) rather than vanity metrics (e.g., total registered users or page hits that do not correlate with business value).

3. Learn Phase

Analyze collected data to determine if the original business hypothesis was confirmed or refuted (validated learning).

4. Pivot or Persevere Decision

Based on learnings:

• Persevere: If data confirms the hypothesis, continue building along the current product strategy.
• Pivot: If data refutes the hypothesis, execute a structured strategic shift (e.g., Zoom-in Pivot, Customer Segment Pivot, Platform Pivot) without changing the overall product vision.

---

Customer Validation Mechanisms

Agile teams employ diverse empirical validation techniques to gather feedback during iterations:

• A/B Testing (Split Testing): Simultaneously routing live user traffic to two different variations of a feature (Variant A vs. Variant B) to measure statistically significant differences in conversion rates or user behavior.
• Hallway Usability Testing: Bringing random users or internal staff unfamiliar with the feature to test an intuitive UI workflow without prior training.
• Net Promoter Score (NPS) & Customer Feedback Loops: Tracking user sentiment and prompt rating prompts embedded directly into software workflows.
• Customer Advisory Boards & Beta Cohorts: Releasing early builds to select cohorts of early adopters willing to tolerate minor bugs in exchange for early access and direct feature input.

---

Spike Solutions: Timeboxed Research Iterations

Originating in Extreme Programming (XP), a Spike is a specialized, timeboxed research user story introduced into a sprint to reduce technical or functional risk. Spikes result in knowledge, prototypes, or data rather than production-ready code.

Types of Spikes

1. Technical / Architectural Spikes: Conducted by developers to investigate technical feasibility, evaluate new libraries/frameworks, test API performance limits, or validate architectural designs before committing to execution.
2. Exploratory / Functional Spikes: Conducted to clarify ambiguous business requirements, investigate complex user interaction designs, or explore regulatory constraints.

Key Rules for Spikes:

• Strictly Timeboxed: Spikes must have a capped effort limit (e.g., 8 hours or 2 days). When the timebox expires, research stops, and the team shares findings.
• Estimated and Tracked: Spikes are estimated like user stories (or assigned fixed timeboxes) and placed in the Sprint Backlog.
• Do Not Produce Production Code: Code written during a spike is disposable prototype code designed purely to acquire knowledge.

---

Iteration & Release Planning Cadences

Agile planning operates at multiple horizons (the Agile Planning Onion). Two critical cadences are Iteration Planning and Release Planning:

• Iteration Cadence (Short-Loop): Typically 1 to 4 weeks. Focuses on producing a Definition of Done-compliant increment for immediate stakeholder review.
• Release Cadence (Long-Loop): Typically quarterly or multi-sprint (e.g., 4 to 6 sprints). Focuses on aggregating MMFs into an MMR for commercial launch.

$\text{Release Date} = \frac{\text{Target Scope}}{\text{Historical Team Velocity}}$

In fixed-schedule agile release planning:

1. The Release Date and Budget are fixed.
2. Team Velocity is estimated using past performance metrics.
3. The Product Owner uses velocity projections to determine which prioritized backlog items will realistically fit into the release window (Flexible Scope).
4. Release burndown/burnup charts are inspected after every sprint to adjust scope buffers as actual velocity varies.