Innovation Sprints
Agile was designed for software delivery — iterating on a solution when the requirements are reasonably understood. Innovation adds a layer of uncertainty that standard Agile was not built for: you are not just building; you are simultaneously discovering the problem, validating your solution, and delivering working software. Running standard Agile under these conditions produces well-organised execution of the wrong thing.
The DLA Stack's third methodology — Agile — adapted for innovation conditions is what this lesson teaches. You have already done the Design Thinking (Lessons 3–4) and Lean Startup work (Lessons 5–7). You have an assumption map with assumption IDs, validated learning from your MVP, and a working business model. Now you build a sprint that is not just a delivery machine, but a learning machine.
This lesson builds directly on two prior lessons. From L05 you have an assumption map with IDs (A-001 through A-010+) and risk tiers. From L07 you have experience with the Build-Measure-Learn loop. The innovation sprint formalises the BML loop into a structured 2-week cadence with explicit goals, measurement, and retrospective assumption updates.
Innovation Sprint vs. Product Sprint
The difference is not cosmetic — it changes how you plan, execute, and evaluate the sprint.
| Dimension | Product Sprint | Innovation Sprint |
|---|---|---|
| Goal type | Delivery ("complete features X and Y") | Learning + delivery ("validate A-004 while building Y") |
| Success definition | Did we ship what we planned? | Did we learn what we set out to learn? |
| Backlog priority | Business value + complexity | Assumption risk × delivery value |
| Retrospective | How do we work better together? | Which assumptions changed status this sprint? |
| Definition of done | Code deployed; QA passed | Code deployed + learning measured + innov.local.md updated |
| Stage | GROWTH (assumptions largely validated) | DISCOVERY, VALIDATION, MVP |
The key adaptation: the sprint must have two goals — a learning goal (which assumption are we testing?) and a delivery goal (what do we build that enables the test?). Without the learning goal, you are running a product sprint and calling it innovation.
Use the Innovation Sprint format when your venture is at DISCOVERY, VALIDATION, or MVP stage — when critical assumptions remain unvalidated. Switch to the Product Sprint format at GROWTH stage, when you have validated product-market fit and are scaling a known solution.
Sprint Plan Components
A complete innovation sprint plan has six components:
1. Sprint goal — Dual statement: what are we learning (reference assumption ID), and what are we building that enables the measurement?
2. Backlog — User stories with acceptance criteria, story points, owner assignment, and assumption ID linkage.
3. Definition of done — Three dimensions: code (deployed and tested), learning (measured for a specific period), and documentation (innov.local.md updated).
4. Mid-sprint check — A Day 7 review: is the critical story on track? Is there any early signal on the learning goal? Is any story at risk?
5. Sprint review format — What to demo, what data to present, whether the assumption was confirmed or invalidated, and what stakeholders say.
6. Retrospective format — What worked, what did not, assumption status updates with evidence, one experiment for next sprint.
User Story Quality
The user story is the unit of work in a sprint. In an innovation sprint, each story should link to an assumption — making it an explicit experiment rather than a feature request.
Weak story:
"As a user, I want a better notification system so that I know things happened."
Problems: "user" is not a specific role; "better notification" is not a precise action; "know things happened" is unmeasurable; no assumption linkage.
Strong story:
"As a CFO at Pilot 3, I want to receive invoice approval requests via WhatsApp (instead of email) so that I can approve on the device I check most frequently. Acceptance criteria: approval messages sent within 2 minutes of invoice ingestion; APPROVE/REJECT captured with timestamp; 24-hour reminder if no response; email fallback if WhatsApp delivery fails. Tests assumption: A-004 (WhatsApp integration feasibility)."
Every element is specific, testable, and linked to an assumption.
| Element | Weak | Strong |
|---|---|---|
| Role | "user" | "CFO at Pilot 3" |
| Action | "get notified" | "receive invoice approval requests via WhatsApp" |
| Outcome | "know things happened" | "approve on the device I check most frequently" |
| Acceptance criteria | "notifications work better" | "messages sent within 2 minutes; APPROVE/REJECT logged" |
| Assumption reference | none | "Tests assumption A-004 (WhatsApp integration feasibility)" |
Backlog Prioritisation
With a full backlog of potential stories, you need a principled way to decide what goes in this sprint. The formula:
Priority Score = Assumption Risk Score (1–3) × Delivery Value Score (1–3)
Maximum score: 9
Assumption Risk Score:
- 3 = Tests a Tier 1 (existential) assumption — if this assumption is wrong, the venture must pivot
- 2 = Tests a Tier 2 (serious) assumption — product changes significantly if wrong
- 1 = Tests a Tier 3 assumption or no assumption (pure delivery)
Delivery Value Score:
- 3 = Blocks the next critical path item — nothing else can proceed without this
- 2 = Enables faster learning — accelerates the next experiment
- 1 = Nice to have — no critical dependency
Build the sprint from the highest-scoring items down. Items scoring ≤2 go to the backlog unless they are quick wins (estimated under 2 hours).
The AP Automation Sprint: Full Plan
The following is the innovation sprint plan for validating WhatsApp adoption in the AP automation venture.
INNOVATION SPRINT PLAN — Sprint 2
Dates: [Start] – [End] | Team: 3 (2 developers, 1 founder) | Velocity: 18 points
════════════════════════════════════════════════════════════
SPRINT GOAL:
Learning goal: Determine whether WhatsApp approval workflow improves
invoice adoption rate vs. email-only by ≥20 percentage points.
Tests assumption: A-004 (WhatsApp integration feasibility) and
A-005 (adoption: CFOs will approve via mobile app in workflow)
Delivery goal: WhatsApp approval workflow deployed in Pilot 3
(currently lowest adoption: 45%); A/B measurement dashboard in place.
SPRINT BACKLOG:
US-001: WhatsApp approval for Pilot 3 [8 points] [Developer 1]
As a CFO at Pilot 3, I want to receive invoice approval requests
via WhatsApp (instead of email) so that I can approve on the device
I check most frequently.
Acceptance criteria:
- Invoice approval messages sent to CFO WhatsApp within 2 minutes
of invoice ingestion
- APPROVE/REJECT response captured and logged with timestamp
- Reminder sent after 24hr no response
- Email fallback if WhatsApp delivery fails
Tests assumption: A-004 (WhatsApp integration feasibility)
US-002: Adoption measurement dashboard [5 points] [Developer 2]
As a founder, I want to see daily adoption rates per pilot customer
(invoices processed through system / total invoices) so that I can
measure the impact of the WhatsApp workflow.
Acceptance criteria:
- Dashboard shows: daily adoption % per customer; 7-day rolling average
- Comparison: pre-WhatsApp vs. post-WhatsApp adoption for Pilot 3
- Exportable to CSV
Tests assumption: A-005 (adoption measurement feasibility)
US-003: Finance team onboarding for Pilot 3 new staff [3 points] [Founder]
As the founder, I want to run a 30-minute onboarding session with
Pilot 3's new finance staff so that adoption is not limited by
knowledge gaps (Pilot 3 had 3 new staff hires in 6 weeks).
Acceptance criteria:
- Session completed with all 3 new staff members
- 1-page quick reference guide created (covers: how to send invoice,
how to approve on WhatsApp, how to use dashboard)
Tests assumption: A-005 (adoption — staff knowledge barrier sub-assumption)
US-004: Competitor research [2 points] [Founder]
As the founding team, we want to identify any competitor who has
recently launched a similar AP solution in our target market
so that we can adjust positioning if needed.
Acceptance criteria:
- Market scan completed; findings documented in innov.local.md
Tests assumption: none — pure delivery (deferred from last sprint)
PRIORITY SCORES:
US-001: Risk 3 × Value 3 = 9 ✓ IN SPRINT
US-002: Risk 3 × Value 3 = 9 ✓ IN SPRINT
US-003: Risk 2 × Value 3 = 6 ✓ IN SPRINT
US-004: Risk 1 × Value 2 = 2 ✓ QUICK WIN (included; est. 4 hours)
DEFINITION OF DONE:
Code: Deployed to production; tested on Pilot 3 with real invoices
Learning: Adoption rate measured for 7 days post-deployment
Docs: Sprint learnings and assumption updates written to innov.local.md
MID-SPRINT CHECK (Day 7):
Review: Is US-001 (WhatsApp integration) deployed to Pilot 3?
Measure: Any early adoption signal? (even 3–4 days of data)
Risk: Is any story at risk of not completing? Adjust scope now.
SPRINT REVIEW FORMAT:
Demo: Show WhatsApp approval flow with real Pilot 3 invoice
Measure: Adoption rate change (pre vs. post — even early data)
Learning: Did we confirm or invalidate the WhatsApp adoption hypothesis?
Input: Pilot 3 CFO on WhatsApp UX — what works, what does not
SPRINT RETROSPECTIVE FORMAT:
What worked? (1 item per person — specific)
What did not work? (1 item per person — specific)
Assumption updates:
A-004 (WhatsApp integration feasibility): [Update with evidence]
A-005 (adoption): [Update with 7-day adoption data]
One experiment for next sprint based on learning:
[Specific change to try based on what we learned]
════════════════════════════════════════════════════════════
Using /sprint for Sprint Planning
The /sprint skill handles the full sprint planning workflow. The most common invocation:
/sprint
Design a 2-week innovation sprint.
Sprint goal: [What assumption are we testing? What are we building to test it?]
Team: [N developers, N founders]
Current venture stage: [DISCOVERY / VALIDATION / MVP]
Open assumptions being tested: [A-00X, A-00X]
Current backlog items: [List the stories you are considering]
Output:
1. Sprint goal statement (learning + delivery)
2. Sprint backlog (user stories with acceptance criteria linked to assumptions)
3. Definition of done (code, learning, documentation)
4. Mid-sprint check template (Day 7)
5. Sprint review format
6. Retrospective format with assumption update template
After the sprint completes, close it with the retrospective:
/sprint
Sprint retrospective for Sprint [N].
What was completed: [List US completed]
What was not completed: [List + reason]
Learning goal result: [Was the hypothesis confirmed, invalidated, or inconclusive?]
Data: [The actual measurement — adoption rate, conversion, etc.]
What worked / did not work: [Team observations]
Output:
1. Assumption status updates (reference A-00X)
2. innov.local.md updates to propose
3. Next sprint priority based on this learning
Innovation sprints work identically inside organisations. The learning goals become: "Will the internal process team adopt the new workflow?" The delivery goals become: "Deploy the process change to Team A as a pilot." The retrospective assumption updates feed back to your internal innovation committee. One adjustment: internal pilots often require an explicit "change management" user story — the humans who need to change their behaviour need support that external customers often do not.
Try With AI
Use these prompts in Cowork or your preferred AI assistant.
Reproduce — Run the chapter's worked example:
/sprint
Design a 2-week innovation sprint for the AP automation venture.
Sprint goal: Validate that WhatsApp approval workflow improves invoice
adoption rate vs. email-only by ≥20 percentage points.
Team: 2 developers, 1 founder (product/sales).
Current venture stage: MVP — 3 paying pilots active.
Current assumption being tested: A-004 (WhatsApp integration feasibility),
A-005 (adoption: CFOs will approve via mobile messaging in workflow).
Output:
1. Sprint goal (learning + delivery)
2. Backlog (user stories with acceptance criteria and assumption IDs)
3. Priority scores (Assumption Risk × Delivery Value)
4. Definition of done
5. Mid-sprint check template (Day 7)
6. Retrospective format with assumption update template
What you are learning: Notice how each user story maps to an assumption ID. The backlog is not a to-do list — it is a set of experiments. The priority scores make the "what goes in this sprint" conversation explicit rather than intuitive.
Adapt — Plan a sprint for a different venture stage:
/sprint
Design a 2-week innovation sprint.
Venture: [A B2B SaaS at VALIDATION stage — first 3 pilots just signed]
Sprint goal: Validate that our onboarding process gets a new customer
to their first successful automated transaction within 3 business days.
Team: 1 developer, 1 founder.
Most critical open assumption: "A-003: Our onboarding takes <3 business
days without white-glove support." (Currently: white-glove; ANECDOTAL)
Target: Demonstrate that self-serve onboarding is possible.
For each user story: include assumption ID reference and binary
acceptance criteria.
What you are learning: At VALIDATION stage, the riskiest assumption is usually about onboarding and adoption — not about the core product. Notice how the sprint goal focuses on the onboarding assumption, not on building more features.
Apply — Plan a sprint for your own venture:
/sprint
Design a 2-week innovation sprint for my venture.
My current stage: [DISCOVERY / VALIDATION / MVP]
My most critical unvalidated assumption: [From my assumption map in L05 — reference A-00X]
What I am currently building or testing: [Current state]
Team composition: [Your team]
Sprint goal should test [A-00X] by [specific measurement].
Include: dual goal statement, 3–5 user stories with assumption IDs,
priority scores, definition of done, mid-sprint check, and retrospective format.
What you are learning: The moment you try to write a learning goal for your venture, you discover whether you know what your most critical assumption is. If the learning goal is vague ("learn whether customers like the product"), you need to return to your assumption map (L05) and identify a specific, testable assumption.
Flashcards Study Aid
Continue to Lesson 14: Four Innovation Agents →