MVP Over the Master Plan: Delivering Working Value When the Epic Is Too Big to Grasp

MVP Over the Master Plan: Delivering Working Value When the Epic Is Too Big to Grasp

When an epic is so large that nobody on the team can hold it in their head, the instinct is to plan harder. Bigger Gantt chart, more workstreams, more dependencies mapped in advance. It feels responsible. It is, in fact, the most dangerous thing you can do — because a detailed plan for work you do not yet understand is not a plan, it is a forecast dressed up as a commitment. The alternative is not chaos. It is the disciplined opposite: ship the smallest piece of real, working value you can, learn from it, and let the next piece be shaped by what you just learned.

The MVP mindset in practice: each sprint delivers one thin, complete slice of value rather than a fraction of everything.

Why the Master Plan Fails in Complex Work

Traditional, plan-driven project management assumes that the scope is knowable at the start. You decompose the goal, estimate every task, sequence the dependencies, and execute the plan. This works beautifully when the work is well understood — building a warehouse, paving a road, rolling out a known package to a thousand laptops. The plan is reliable because the future is reliable.

Complex data and software work is not like that. The hardest questions — what does the source data actually look like, what do stakeholders really mean by "the report", which transformations are correct, where the edge cases hide — cannot be answered from a planning room. They can only be answered by building something and looking at the result. In that world, a 200-line plan is not a map of the territory. It is a detailed map of a territory the team has never visited, drawn from rumour. The more detail it contains, the more confidently it points in the wrong direction.

What an MVP Actually Is — and What It Is Not

A Minimum Viable Product is the smallest slice of a larger goal that delivers real value to a real user and runs in the real environment. Every word in that sentence carries weight. Smallest, because the point is to learn fast and cheaply. Real value, because a slice that nobody can use teaches you nothing. Real environment, because something that only works on a developer laptop has not reduced any of the risk that matters.

The most common misunderstanding is to confuse "minimum" with "unfinished" or "low quality". An MVP is not a broken version of the full product. It is a complete, production-quality version of a deliberately narrow slice of it. The narrowing is in the scope, never in the quality. One report, for one business question, built properly and running in production, is an MVP. Five reports, all half-built and none deployable, are not.

MVP and the Heart of Scrum: Working Software Every Sprint

This is not a new idea bolted onto Agile — it is Agile. Scrum exists to turn an uncertain goal into a series of short, inspectable increments. The first value of the Agile Manifesto puts working software ahead of comprehensive documentation, and the Scrum framework operationalises that by demanding a potentially shippable increment at the end of every sprint. The MVP mindset is simply taking that demand seriously: instead of asking "how much of the epic can we plan", the team asks "what is the smallest piece of this epic we can put into production this sprint?"

That question changes everything. It forces the epic to be cut vertically — a thin, complete slice from source to delivered value — rather than horizontally into layers that only have worth once the last layer lands. It gives the Sprint Review something honest to show: not a status update, but working output a stakeholder can react to. And it converts the team's biggest enemy, uncertainty, into its fuel: every increment retires a real risk and teaches the team something it could not have known by planning.

The One Thing You Decide Up Front: The Platform

There is a crucial exception to "do not plan what you do not know", and getting it wrong is one of the few mistakes an Agile team genuinely cannot iterate its way out of. The foundational platform must be chosen deliberately, up front. You can — and should — discover the requirements, the data shapes, and the right transformations slice by slice. But you cannot discover, slice by slice, whether you are building on the right database, the right cloud, the right data platform. Those choices are expensive and slow to reverse, and a team that starts shipping MVPs onto the wrong foundation is simply accumulating work that will have to be torn down.

So the rule is a clean split. Decide the environment up front; discover the product incrementally. Choose the platform, the governance model, and the architectural pattern before sprint one — then never let that decision be an excuse to also plan the entire epic in advance. For the programme this article is grounded in, that foundational decision is Databricks, and getting its architecture right is what makes fast MVP delivery possible rather than reckless.

Getting Databricks Right: The Medallion Architecture

It is worth being precise here, because the platform decision is the one that has to be correct. Databricks structures data using the Medallion Architecture — a progressive refinement of data through three layers, conventionally named Bronze, Silver, and Gold. Each layer raises the quality and business-readiness of the data.

The MVP as a Thin Slice Through Bronze, Silver and Gold

It is tempting to say "the MVP is the Gold layer" — Gold is, after all, where the business sees value. But you cannot build Gold on its own. Gold is fed by Silver, which is fed by Bronze. A Gold table with no pipeline beneath it is a hand-crafted artefact that breaks the moment the source data changes. That is a demo, not working software.

The production MVP is therefore a thin vertical slice that threads all three layers for one narrow use case. You pick a single business question. You ingest just the source data that question needs into Bronze. You conform just that data in Silver. You build the one Gold table that answers the question. And you deploy it. Narrow scope, full depth.

Federation is the secret weapon of the first MVP. Before committing engineering effort to ingestion pipelines, an early sprint can federate directly to the source and ship a working report in days. If the report proves its worth, the next MVP replaces the live federation with a proper Bronze-to-Gold pipeline. If it does not, you have lost days, not a quarter.

The bottom row delivers usable transport at every stage. The top row delivers nothing until the very end.

The Business Function Backlog: The Iceberg Model

The MVP mindset in practice: each sprint delivers one thin, complete slice of value rather than a fraction of everything.

A large backlog is not a problem. It is a sign of a healthy, engaged business function that has been honest about everything it wants to improve. A bank's Finance function will naturally accumulate hundreds of items over time — regulatory requirements, management reporting requests, audit findings, system migrations, improvement feedback from live services. A backlog representing five or more years of potential work is not a cause for alarm. It is a cause for good Product Ownership.

The mistake is not having a large backlog. The mistake is treating every item in it as equally urgent, equally refined, and equally deserving of the team's attention right now. That mistake is what turns a healthy backlog into a source of paralysis.

The Iceberg: Only the Top Stories Need to Be Ready

Mike Cohn's iceberg analogy captures this perfectly. Think of the backlog as an iceberg floating in the ocean. The stories visible above the waterline — roughly the top twenty — are fully refined: written in detail, acceptance criteria agreed, dependencies understood, and ready to be pulled into a sprint. Everything below the waterline exists, and it matters, but it is rough. It does not need to be detailed yet, because it is not needed yet.

As the team pulls stories off the top of the iceberg — completing them sprint by sprint and delivering them as working software — the iceberg rises. Stories that were just below the waterline float up into view. The Product Owner refines them and they become the next set of sprint-ready stories. The backlog is always large. The refined, actionable portion at the top is always small, focused, and manageable.

The Product Owner: From Idea to Done Done

The mechanism that makes the iceberg work is a genuine Product Owner — the person who, on behalf of the business function, owns and manages its requirements because they understand what the function needs, why it needs it, and in what order it needs it. This is not a technical role and it is not a proxy role. It is a senior business representative who has enough authority to speak for the function and enough knowledge of its operations to translate ideas into actionable requirements.

The Product Owner's defining responsibility is closing the loop from idea to done done. In a truly Agile business function, that loop looks like this: a business idea or need is captured as a rough backlog item below the waterline. As it rises, the Product Owner shapes it into a properly written requirement — a user story with clear acceptance criteria the team can build against. The team builds it in a sprint and presents it at the Sprint Review. The Product Owner inspects the increment and either approves it — done — or rejects it with specific feedback. Once approved, the increment is shipped to production. That is done done: working software in the hands of the people who need it. At that point, and only at that point, the story leaves the iceberg permanently and enters the Service Catalogue as a live, supported service.

The Product Owner's core responsibilities in a business function:

• Translating ideas into requirements. The Product Owner understands the function's needs well enough to turn rough backlog items into properly written user stories — acceptance criteria agreed, dependencies understood, ready for the team to build.
• Maintaining the waterline. At any given time, roughly the top twenty stories are refined and sprint-ready. Everything below is captured but deliberately left rough until it floats up.
• Approving the increment — done to done done. At the Sprint Review, the Product Owner inspects the increment against the agreed acceptance criteria and approves it. Approval is the trigger for shipping to production. Approval means the Product Owner is satisfied it meets the business need, not merely that the technical work is complete.
• Managing stakeholder expectations. The Product Owner is the single point of truth for what is coming, when, and why other things are not. New requests go into the backlog at the right depth — they do not jump the queue unless the Product Owner explicitly decides they should.

Vertical Slicing Inside the Business Function

The iceberg model also shapes how stories are written. A Finance function should not place "build the management reporting suite" as a single item in the backlog. That is a boulder, not a story — it cannot float above the waterline because it is too large to refine or deliver in a sprint. Instead it should be decomposed into thin, vertical slices: "month-end P&L variance report for the CFO, sourced from the general ledger, live in production". That is one story. The suite emerges sprint by sprint as each slice floats up, is refined, and is delivered.

Connecting to ITIL: Pipeline, Catalogue, CSI, and Retirement

ITIL — the Information Technology Infrastructure Library — is the most widely adopted framework for managing IT services. Where Scrum describes how to build things, ITIL describes how to run them once built, how to keep improving them, and — crucially — how to know when to stop running them. For business functions working alongside a Scrum delivery team, ITIL provides the governance vocabulary for the full lifecycle of every service the team ships.

The four ITIL concepts that connect most directly to the iceberg and MVP model are the Service Pipeline, the Service Catalogue, Continual Service Improvement (CSI), and Service Retirement. Together they describe what happens to a story after it leaves the top of the iceberg.

The Service Pipeline: Stories in Flight

The Service Pipeline is the set of services currently being built — everything that has risen above the iceberg's waterline, been pulled into a sprint, and is on its way to production. For the business function, the pipeline answers the question "what is coming, and when?" in a concrete, sprint-by-sprint sense.

The Finance function's Product Owner, looking at the pipeline, can see that "automated month-end P&L variance report" is two sprints away and "budget vs actuals dashboard by cost centre" is four sprints away. This gives the function enough lead time to prepare — train users, update process documentation, notify auditors — without locking the delivery team into false precision about everything further out. When a new regulatory requirement arrives with an urgent deadline, the Product Owner can point to the pipeline, show what would need to move, and have a genuine conversation about priority rather than simply absorbing the new item invisibly into a backlog nobody reads.

The Service Catalogue: What Is Live and Supported

When a story completes its sprint, passes the Sprint Review, and is deployed to production, it becomes an entry in the Service Catalogue — the register of services currently live, supported, and available to users. A service only earns its place in the Catalogue when it is fully operational: documented, owned, with a known refresh schedule and a clear process for handling failures.

For the bank's Finance function, the Catalogue might look like this after six months of delivery:

• Month-end P&L variance report — live, refreshed nightly from the general ledger, owned by the Finance Data team.
• Cost centre budget vs actuals — live, self-service via the Finance dashboard, refreshed daily.
• Intercompany reconciliation summary — live, automated exception flagging included.

Each of these was once a rough idea below the iceberg's waterline. It floated up, was refined, was delivered as an MVP slice threading Bronze through Silver to Gold in Databricks, and is now a supported service. The Catalogue makes that journey tangible — not in story points, but in services people rely on every working day. It also makes something else visible: what the team used to do manually that can now stop.

Service Retirement: Closing the Loop

This is the step that most delivery programmes skip, and skipping it is expensive. Every time a new Databricks-powered service enters the Catalogue, there is almost certainly an older service it supersedes — a manual Excel report, a legacy SQL query run by hand each month-end, a third-party tool the business paid for before the data platform existed. If the old service is not formally retired, the business function ends up running both in parallel: the new automated service and the old manual process, side by side, consuming time, creating confusion about which number is correct, and eroding trust in the new platform.

Service Retirement is the formal process of decommissioning a service that is no longer needed. Once the Databricks-powered month-end P&L report has run successfully for an agreed number of cycles and the business has validated its output, the manual Excel process is switched off. The spreadsheet is archived. The time the Finance analyst spent producing it every month is freed for higher-value work. The Gold table in Databricks is the single source of truth, and there is no fallback that quietly undermines it. Retirement also feeds back into the backlog — the capacity freed by retiring an old service can be redirected to further items on the iceberg or to improving live services through CSI.

Continual Service Improvement: What Gets Better

CSI is ITIL's answer to the question every business function eventually asks: "the service is live, but it is not quite right yet — what now?" It is a formal lifecycle stage in which live Catalogue services are measured, gaps are identified, and improvement actions are fed back into the backlog — where they join the iceberg, floating up to the waterline in priority order alongside new capability work.

CSI prevents two failure modes that commonly afflict business functions after a delivery programme:

• The "done and forgotten" failure. A service is delivered, the team moves on, and nobody owns the ongoing quality of what was built. The Gold tables drift. The numbers stop being trusted. Users rebuild the shadow spreadsheets. CSI makes improvement of live services a permanent, first-class source of backlog items — not an afterthought that surfaces only when something breaks.
• The "never good enough to launch" failure. The business function refuses to accept a service into the Catalogue because there are still improvements to make. CSI solves this by separating launch from perfection: the service goes live when it is viable, and the improvements join the backlog as CSI stories to be delivered in subsequent sprints. The iceberg keeps moving.

The Full Lifecycle: From Waterline to Retirement

The Finance function that operates this model never drowns in its backlog, because the backlog is an iceberg — large by design, but only ever sharp at the top. It never loses track of what the team has delivered, because the Catalogue is the living record. It never lets good services decay, because CSI keeps feeding the iceberg. And it never wastes effort running old processes alongside new ones, because Retirement closes the loop every time a new service supersedes an old one.

Is Your Epic About to Overwhelm the Team?

Complex epics overwhelm teams in recognisable ways, and the warning signs appear long before the deadline does. The contrast below is the difference between a team drowning in an un-graspable epic and a team that has cut it into deliverable slices.

Why This Compounds: Learn, Iterate, Improve

The deepest argument for MVP over the master plan is not speed — it is learning. A complex epic is, at its core, a pile of unknowns. Every MVP you ship converts one of those unknowns into knowledge: how the source data really behaves, what the stakeholder actually meant, how long the pipeline really takes to run, where the data quality really breaks down. The team that has shipped four MVPs is not just four slices closer to done — it understands the problem in a way no amount of up-front planning could have produced.

That learning compounds. The fifth slice is faster than the first because the team now has working pipelines to extend, conventions that have proven themselves, and a Definition of Done that has met production. The estimates get better not because the team got better at guessing, but because the work stopped being a guess. This is the empirical engine at the heart of Scrum — transparency, inspection, adaptation — applied to delivery: build something real, look at it honestly, and let what you see shape what you build next.

A massive traditional plan, by contrast, front-loads all the deciding into the moment of least knowledge and then spends the rest of the project defending those decisions against reality. The MVP approach does the opposite: it makes the smallest possible decision, learns from it, and earns the right to make the next one. For an epic too big to grasp, that is not just a nicer way to work. It is the only way that reliably ends in a working solution.