Delivery
Discovery
Discovery is where a vague ambition becomes a scope a sponsor can fund. No production code is written. The output is an agreed brief: who it is for, what done means, and what could make the plan wrong.
In brief, then in detail
- The business problem. Why this work exists, who feels the pain, and what a good outcome would change in the operating numbers or in the working day.
- Users and stakeholders. The people who decide, the people who operate, and the people who will live in the software. Their success is not always the same sentence.
- Scope, assumptions, constraints. What is in, what is out, what we are treating as true, and what we cannot change: date, budget, regulation, or a system that must stay.
- Risk worth naming now. Dependencies, missing decisions, and the items that move cost or date. A risk that is only discovered in sprint six was usually visible here.
How it is run
Discovery is the initiating work. Qualified engagements begin with a free consultation. The written output is a discovery document the later phases are priced against. It is deliberately short enough to be read by a chief executive and specific enough for a technical lead to estimate. An NDA comes before confidential material. Discovery is usually one to two weeks.
PriceFree for qualified engagements
DurationUsually 1–2 weeks
OutputA brief the estimate stands on
Discovery outputs
- Charter
- Stakeholder list
- Scope in and out
- Assumptions
- Constraints
- Risk log
Terms, in plain language
- Project charter. The one-page authority to proceed: the purpose, the sponsor, the outcome, and the boundaries.
- Scope statement. What the work includes and, just as important, what it does not. Silence is not scope.
- Assumption. Something treated as true so the plan can exist. If it turns out false, the plan is revisited.
- Constraint. A limit that is not optional: a date, a budget, a law, a platform, or a team you already have.