The phase starts with a kickoff instead of a complete request
If the current process, the people, and a reachable owner are missing, the rooms reconstruct the ask. That is intake, delayed and more expensive.
Software discovery phase
How to run a software discovery phase
A software discovery phase finishes the questions, both estimates, and a recorded yes on the original request. It is not a kickoff week, a sprint zero, or a Definition of Ready checklist. Run it before anyone opens a board.
For product, IT, and department leads who keep scheduling a discovery week and still open the first sprint with unanswered questions.
A software discovery phase is finished when
- Project-specific questions live on the original request
- Answers that would change the build are closed or visibly open
- Both estimates and a recorded yes sit on that same record
Most teams run a kickoff week and call it a software discovery phase
A calendar full of rooms is not discovery. People retell the slogan, invent tasks, and leave with a board that still has no first-release boundary. How to run a software discovery phase is operational: finish the questions on the request, size both sides, and record a decision. Then—and only then—open a sprint.
Questions live in slides, notes, and a later spec
Each paste is a chance to drop a constraint. Testers later open a ticket that never saw the original answer.
A sprint is opened to “figure it out”
Sprint zero and an empty backlog train the team to invent scope where they are supposed to commit. Discovery already failed.
Software Discovery Method: Finish the Questions Before Anyone Books a Kickoff
Treat the software discovery phase as a gate on one record, not as a week on the calendar. A department owner and an IT lead can run it. Do not hire a facilitator to translate the request into a packet, and do not open a board to discover the product.
The phase cannot start from a slogan. Put the current process, the people, and a reachable owner on software project intake before anyone books a kickoff.
Once the story is understandable, requirements gathering software keeps the project-specific questions and reviewed answers on that same record.
If the only “discovery” today is a week of meetings, replace the calendar with requirements gathering software and record a yes before anyone opens a sprint.
- 1
Start from a complete request, not a calendar invite
The phase begins when a stranger can understand the current process, who is affected, the outcome, the owner, and the hard limits.
If those facts are missing, send the request back. Booking rooms will not invent them. A software discovery phase that starts with a slogan becomes a kickoff week.
- 2
Ask project-specific questions on the same record
Write the follow-ups that this change actually needs—people, information, rules, and integrations—next to the original story.
A generic questionnaire is not discovery. “Who approves a reservation after hours?” belongs on this request. “List all stakeholders” belongs in a template graveyard. Do not open a new document to formalize the answers.
- 3
Close the answers that would change the build
Settle behavior that would alter the first release if answered later. Leave true unknowns visible.
Access rules, notification behavior, and “must stay unchanged” constraints become mid-sprint inventions if they stay in someone’s head. An open question on the record is safer than an assumed answer in a kickoff deck.
- 4
Estimate both sides against a first-release boundary
Size training and adoption next to the build. A developer range is not the whole phase.
If only technical hours exist, you have a quote—not a software discovery phase. Write the business estimate on the same record. Then leaders can see the total change, not just the code.
- 5
Record yes, no, or not yet before anyone opens a sprint
The decision cites the outcome, the exclusions, the remaining unknowns, and both estimates.
A Definition of Ready checklist on a ticket is not this gate. Ready here means the organization already decided. Sprint planning sequences approved work. It does not finish discovery.
Practical template
Software discovery phase done checklist
If a row fails, do not book a kickoff or open a sprint to invent the answer. Send the request back one step. The examples use a fictional volunteer scheduling change.
Software discovery phase done checklist
The original request is understandable
Why it belongs in the phase
Discovery cannot start from a product name and a hoped-for month.
What done looks like
Staff reserve facilities by email and a spreadsheet; volunteers give up by day three.
Questions are specific to this change
Why it belongs in the phase
A reused questionnaire hides the decisions that would alter this build.
What done looks like
Who approves an after-hours reservation, and which payment vendor cannot move?
Answers that change behavior are closed or visibly open
Why it belongs in the phase
Assumed answers become mid-sprint scope. Open questions stay cheaper.
What done looks like
After-hours approval is a named supervisor. Public status page is still unknown.
First-release exclusions are written
Why it belongs in the phase
Without an edge, every later idea sounds like part of the same phase.
What done looks like
No historical import and no mobile app in the first release.
Business and technical estimates exist
Why it belongs in the phase
A code-only number hides training, procedure change, and first-month support.
What done looks like
IT sizes submit-and-track in the current identity vendor. Operations sizes two training sessions and coverage.
A recorded decision cites both numbers
Why it belongs in the phase
A kickoff agenda is not a yes. A sprint zero is not a yes.
What done looks like
Yes to two-day event setup in the current vendor. Historical import stays out.
Testers can still open the same record
Why it belongs in the phase
If QA later opens a ticket paraphrase, the phase already forked.
What done looks like
The living answers stay on the request. No second spec is opened to “formalize” them.
| Check | Why it belongs in the phase | What done looks like |
|---|---|---|
| The original request is understandable | Discovery cannot start from a product name and a hoped-for month. | Staff reserve facilities by email and a spreadsheet; volunteers give up by day three. |
| Questions are specific to this change | A reused questionnaire hides the decisions that would alter this build. | Who approves an after-hours reservation, and which payment vendor cannot move? |
| Answers that change behavior are closed or visibly open | Assumed answers become mid-sprint scope. Open questions stay cheaper. | After-hours approval is a named supervisor. Public status page is still unknown. |
| First-release exclusions are written | Without an edge, every later idea sounds like part of the same phase. | No historical import and no mobile app in the first release. |
| Business and technical estimates exist | A code-only number hides training, procedure change, and first-month support. | IT sizes submit-and-track in the current identity vendor. Operations sizes two training sessions and coverage. |
| A recorded decision cites both numbers | A kickoff agenda is not a yes. A sprint zero is not a yes. | Yes to two-day event setup in the current vendor. Historical import stays out. |
| Testers can still open the same record | If QA later opens a ticket paraphrase, the phase already forked. | The living answers stay on the request. No second spec is opened to “formalize” them. |
Worked example
What a finished software discovery phase looks like
A volunteer coordinator submitted a complete request. Discovery stayed on that record. Nobody booked a kickoff week, and the first sprint did not invent the product.
What a finished software discovery phase looks like
Request
What we recorded
Volunteer scheduling still runs on email and a spreadsheet
Questions asked
What we recorded
After-hours approval, payment vendor, and who trains shift leads
What stayed open
What we recorded
Public status page—named as unknown, not assumed away
First-release edge
What we recorded
Two-day event setup. No historical import. No mobile app.
Both estimates
What we recorded
IT hours in the current identity vendor plus operations training time
Decision
What we recorded
Yes against that boundary. Sprint planning may now slice the work.
| Check | What we recorded |
|---|---|
| Request | Volunteer scheduling still runs on email and a spreadsheet |
| Questions asked | After-hours approval, payment vendor, and who trains shift leads |
| What stayed open | Public status page—named as unknown, not assumed away |
| First-release edge | Two-day event setup. No historical import. No mobile app. |
| Both estimates | IT hours in the current identity vendor plus operations training time |
| Decision | Yes against that boundary. Sprint planning may now slice the work. |
The phase succeeded because the questions, the exclusions, both estimates, and the yes stayed on the request. A kickoff week would have produced tasks. A sprint zero would have produced a board. Neither would have finished discovery.
A kickoff week vs. a finished discovery phase
A kickoff week vs. a finished discovery phase
A calendar of rooms and a hoped-for go-live
Discovery phase that finishes the questions
A complete request, then project-specific questions
Notes, slides, and a later “formal” spec
Discovery phase that finishes the questions
Answers on the same record the requestor wrote
A sprint zero or an empty backlog to figure it out
Discovery phase that finishes the questions
Both estimates and a recorded yes before a board exists
A Definition of Ready checklist on the first ticket
Discovery phase that finishes the questions
Ready means the organization already decided
| Kickoff week that invents the work | Discovery phase that finishes the questions |
|---|---|
| A calendar of rooms and a hoped-for go-live | A complete request, then project-specific questions |
| Notes, slides, and a later “formal” spec | Answers on the same record the requestor wrote |
| A sprint zero or an empty backlog to figure it out | Both estimates and a recorded yes before a board exists |
| A Definition of Ready checklist on the first ticket | Ready means the organization already decided |
What not to treat as a software discovery phase
Booking a kickoff week and calling it discovery
Rooms reconstruct a slogan. If the request is incomplete, send back the missing answers. Do not schedule a séance.
Running sprint zero to invent the product
A sprint is for approved work. Opening an empty backlog to “discover as we go” is how the first increment becomes the entire wishlist.
Using a Definition of Ready checklist as the gate
Ticket hygiene—sized, criteria written, dependencies named—is later. The software discovery phase decides what the organization is buying.
Confusing this with product discovery
Ranking ideas and publishing a roadmap is a different job. Software discovery finishes one request: questions, both estimates, and a yes. Keep idea scoring where it already lives.
In Precision Foundry
How Precision Foundry runs this software discovery phase on one record
The method above is operational: a complete request, project-specific questions, both estimates, and a recorded yes before anyone opens a sprint. Precision Foundry stores that same data thread so the QA tester opens what the business user wrote—not what a kickoff week turned into tickets.
- Guided questions attach to the original software request
- Open answers stay visible instead of hiding in meeting notes
- Business and technical estimates sit on that same record
- A recorded yes happens before a board or a tracker copy exists
Common questions
Questions about software discovery phase
How do you run a software discovery phase?+
Start from a complete software request. Ask project-specific questions on that same record. Close the answers that would change the build, or leave them visibly open. Estimate business and technical effort against a first-release boundary, then record a yes, no, or not yet before anyone opens a sprint.
Is a kickoff week the same as a software discovery phase?+
No. A kickoff week reconstructs the ask in rooms. A software discovery phase finishes written questions, both estimates, and a decision on the original request. If you need a week of meetings, the request was not ready.
How is software discovery different from product discovery?+
Product discovery ranks ideas and publishes a roadmap. Software discovery finishes one change: the questions, both estimates, and a recorded yes. Keep idea scoring where it already lives. Do not treat a scored bet as a complete request.
Do we need a sprint zero to finish discovery?+
No. A sprint zero is an empty board pretending to be a phase. Finish the questions and the decision first. Sprint planning then slices approved work. It does not invent the product.
Is a Definition of Ready checklist enough?+
Not for this job. A Definition of Ready checklist usually means a ticket is sized and has criteria. A software discovery phase means the organization already decided what the first release is. Ticket hygiene comes after that yes.
When is the software discovery phase done?+
When a stranger can retell the request, the answers that change behavior are closed or named as unknown, both estimates exist, and a recorded decision cites that boundary. Then a sprint may start. Not before.
Try How to run a software discovery phase on one real request
Precision Foundry keeps this guide attached to the request so the template does not live in a forgotten doc.
Request Private Alpha