Why delivery-only teams eventually stall
A team that only ever builds what is already fully specified will ship reliably for a while and then stall, because nothing in the last several Sprints changed as a result of anything the team actually learned. This module treats that as the definition of a delivery-only team, and opens with opportunity solution trees as a plain-language tool for keeping a real question live above every solution the team considers, rather than jumping straight from a stated problem to a single favoured solution, which the module bluntly calls a roadmap wearing a costume.
The core discipline taught here is assumption mapping: before any epic enters the backlog, the team spends a few minutes asking what has to be true for this to work, and which of those things has no supporting evidence yet. A ranking game forces prioritizing assumptions by risk rather than by however interesting they are to investigate, and a companion lesson on the smallest test that could change your mind pushes teams away from testing what they already know, which is comfortable, and toward testing the assumption that would actually be embarrassing to be wrong about.
The module's central practical contribution is showing discovery living inside the delivery Sprint rather than as a separate research track that gets cut the first time a Quarter gets busy. It covers continuous interviewing without a dedicated research team, a scenario where a stakeholder insists they already know the answer and pressure-tests whether that confidence is backed by evidence, and closing the loop by killing ideas that evidence does not support, which the module treats as equally valuable as validating ones that do, because a killed idea early is far cheaper than a shipped one that fails.
Mistakes teams make with this material
Building an opportunity tree with exactly one solution under each opportunity, which functions as a roadmap dressed up in discovery language rather than a genuine exploration of options.
Spending discovery effort validating what the team already believes, and quietly avoiding the assumption that would be embarrassing to discover is false.
Running discovery only when the calendar has slack, rather than budgeting it as a protected part of every Sprint, which guarantees it vanishes the first time delivery pressure increases.
Skipping a test because a senior stakeholder says they already know the answer, without asking what evidence actually supports that confidence.
Questions people ask
How do you know if a team is actually doing discovery or just delivering?
Check whether anything in the last few Sprints changed direction because of something the team learned. If every Sprint simply executes a plan set months ago with no adjustments, the team is delivering only, regardless of what any dashboard or backlog label claims.
What is an opportunity solution tree and why do teams get it wrong?
It is a structure connecting a desired outcome to the problems, or opportunities, that could move it, and then to multiple candidate solutions for each. Teams get it wrong by listing exactly one solution per opportunity, which is a roadmap in different formatting rather than a genuine set of options.
How do you prioritize which assumptions to test first?
Rank by risk: which assumption, if wrong, would cause the most damage, combined with how little evidence currently supports it. Test the risky, unproven assumptions first, not the ones that are simply the most interesting or easiest to check.
How does discovery fit inside a normal delivery Sprint without derailing it?
Budget a fixed, protected amount of Sprint capacity for discovery activities explicitly, the same way capacity is protected for support work or technical debt, rather than treating it as leftover time that evaporates whenever delivery pressure rises.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
A team ships every Sprint, on time, for two years, and no product metric moves. What is most likely missing?
- A better Definition of Done
- Discovery: evidence about whether the work is worth building
- More story points
- A larger team
Delivery answers 'can we build it right'. Discovery answers 'should this exist', and nothing in the Sprint cadence supplies that by default.