What to Expect in a Microsoft Fabric Discovery Sprint: An Honest Scope

One tells you that your goods receipt table has 41,000 rows with a null supplier code and that OTIF is defined differently by the plant and the commercial team. The other tells you data is a strategic asset and recommends a phased approach — something your own team could have written in a day, for which you paid four weeks.

This is a scope document written by the person who runs these: what a real discovery contains, the deliverables worth paying for, the filler to refuse, and the client time it actually costs.

A discovery sprint exists to produce two decisions: whether to proceed with a build at all, and if so, the exact scope, sequence and fixed price of the first slice. It is not a roadmap exercise. Its worth is measured by the accuracy of the estimate that follows and by the defects it finds early.

A roadmap is a statement of intent, and intent is free. An estimate is a commitment, and a commitment is only as good as the evidence under it. Discovery buys that evidence at a fraction of what it costs to find mid-build, when the fix arrives as a change request. The test: at the end, can the partner quote a fixed price for the first slice and stand behind it?

Five named activities across two to three weeks. Week 1 — source inventory (half a day) and, more importantly, access. Read credentials on a production ERP need an owner, a security review and a named approver; on-premises sources need the gateway installed inside your network. Ask the partner to send the access request list before the contract is signed — one who does that has run this before.

Week 1–2 — profiling the actual data, not the data dictionary. The output is specific: row counts and date ranges per table, null rates per key column, duplicate rates on every join column, orphaned foreign keys, and the share of records where a mandatory field holds a placeholder. One caution: Power Query profiles the first 1,000 rows by default, so serious profiling runs in a Fabric notebook against the full extract. If the report names no defect with a number attached, ask what was run.

Week 2 — metric definition interviews (the plant, commercial and finance separately on the same three KPIs; you will get three definitions of OTIF), and capacity sizing with the reasoning shown (the F64 licence boundary usually dominates cost more than compute does). Week 2–3 — the technical spike: take one genuinely awkward source, land it in OneLake, model it to the grain the business argues about, and put a number on a page someone recognises. A spike against sample data proves nothing — sample data is clean by definition, because someone chose it to make the demonstration work.

Discoveries run over because client time was assumed rather than booked. Across three weeks:

That is 27–42 hours across six people. If the ERP owner is unavailable for two of the three weeks because of month-end close, the discovery does not compress, it slips. Check the operational calendar before setting the start date — the most common cause of overrun I see, and it sits entirely with the client.

Four deliverables justify the fee; three common ones are filler:

A proportionate discovery costs roughly 8–15% of the first-phase build it scopes. Below that range the assessment is usually too thin to support a fixed price. Above 20%, discovery has become the project, and the buyer is funding analysis the build will redo. The useful framing is not the number but what the proportion buys: discovery should narrow the uncertainty band on the build estimate from something like ±50% to ±15%. If it does not narrow the estimate, it was not discovery, whatever it cost.

Two commercial notes. A partner willing to credit part of the discovery fee against the build has something at stake. And insist discovery is separately terminable — bundled inside a twelve-month contract, the recommendation to proceed was made before any data was profiled.

• Which of your people will be on this, by name, and are they the people who will build it?
• What access do you need, and can you send that list before we sign?
• Will you profile full tables or a sample? Which tool, run by whom?
• What will the spike move, from which source to which output?
• Will you quote a fixed price for the first slice at the end? If not, why not?
• What is your capacity sizing method, and will you show the arithmetic?
• How many hours of our people's time do you need, by role?
• What have you found in previous discoveries that stopped a project?
• Is discovery separately terminable, and is any fee credited against the build?
• If the answer is "do not proceed yet", will you say so in writing?

That last question changes the conversation. Watch the pause.

Three legitimate outcomes. Proceed on the scoped slice — the data supports it, definitions are agreed, the sponsor is real, and a fixed-price first slice is signed. Proceed on a different slice — the intended use case depends on a source with a defect that takes months to fix commercially, so changing target because the evidence changed is discovery working, not failing.

Or do not proceed yet — this happens and should be said plainly. The usual triggers: no named business owner for the decision the platform supports; an ERP migration already in flight that will invalidate the source model mid-build; an operating decision that cannot be made faster even with better information; or nobody to own the platform after handover. A discovery that concludes "not yet" and states what has to be true first has saved you the build budget.

Discovery cannot fix a source that has no data — if shift-level downtime was never captured, no assessment creates it, and instrumentation becomes a prerequisite project with a longer clock. A fixed price is only as good as its boundary — fixed price on a scope that says "integrate the ERP" is not fixed; it has to name tables, entities, metrics and report pages. Profiling shows today's data, not the governance behind it — a table that profiles clean today degrades the moment a new plant, distributor or pack code arrives.

The spike proves feasibility, not performance at volume — moving one month of one table proves the connection works, not that five years of history refresh inside the window. Discovery cannot manufacture a sponsor — if no operating leader will own the decision, the assessment will be accurate and the programme will still stall. And two to three weeks bounds the depth — nine source systems in three weeks is reconnaissance-depth profiling, not audit depth, so narrow the source list or lengthen the sprint, but be told which.

Four questions to answer before commissioning:

• What decision is the platform meant to change, and who makes it today? Name the person and the meeting. If neither exists, that is the first finding
• Can we grant read access to our ERP within two weeks? If the answer involves a committee, start now, not on day one of the sprint
• Do plant, commercial and finance define our top three KPIs identically? Ask each separately, before they compare notes
• Is an ERP change, plant commissioning or acquisition in flight in the next six months? If so, the source model is moving and the sequence changes

At MyData Insights, discovery is the Discover phase of a Discover → Prototype → Deploy → Expand engagement, run under a Fractional Data Consultant model. First value in six weeks means a working slice against your real data — and it starts with a discovery honest enough to say when those six weeks should wait.