On Scope, Value, and Projects That Delivered the Wrong Thing
You have fought through eight worlds.
Goombas. Koopas. Piranha plants. Moving platforms over bottomless pits. Fire bars. Bullet Bills. You have timed every jump, memorized every pattern, survived every trap.
You reach the castle. You find Toad.
And Toad says it.
“Thank you, Mario! But our Princess is in another castle!”
The delivery is complete.
The objective was met.
The enemy was defeated.
The castle was reached.
And the value is still somewhere else.
The Organizational Echo
This moment happens in organizations every week.
A project is delivered on time. The scope was met. The budget held. The steering committee approved. The go-live happened. The launch email was sent. The lessons-learned document was filed.
And somewhere — in a support queue, in a customer complaint, in a team that still works around the new system, in a KPI that did not move — the actual value is waiting.
In another castle.
The project succeeded. The mission did not.
This is not a story about failure. It is a story about a more dangerous condition: the illusion of delivery.
When delivery becomes the destination, value becomes an afterthought. When the castle is the goal, no one thinks to ask whether the princess is actually in it.
Delivery Is Not Victory
In Civilization, we asked: what is the victory condition?
In Red Alert, we asked: does the economy exist to execute the strategy?
Mario adds the third question — and it is the one most projects skip entirely:
When we deliver this, will value actually be there?
Not: did we build what we planned to build?
Not: did we ship on the date we committed to?
Not: did we stay within the approved budget?
Those are delivery questions. They matter. But they are not value questions.
The value question is harder. It requires knowing — before the first sprint, before the first line of code, before the first vendor contract — what change in the real world would constitute success. Not delivery. Not output. Success.
Delivery is not victory if value is still in another castle.
Scope Is Not the Same as Value
Here is how the confusion begins.
A project is scoped. Requirements are gathered. A backlog is created. A roadmap is built. A team is assembled. Work begins.
And from that moment, a quiet substitution takes place.
The goal shifts — gradually, invisibly, without anyone deciding — from delivering value to delivering scope.
The backlog becomes the definition of success. Completing the backlog becomes the mission. The castle becomes the destination.
This substitution is not malicious. It is structural. Scope is visible. Scope is trackable. Scope produces the green on the dashboard, the percentage complete on the report, the velocity chart in the sprint review. Scope is what gets reported to the steering committee, approved in the budget cycle, celebrated at the go-live party.
Value is harder to see. Value lives outside the project. Value shows up in whether customers behave differently, whether operations actually improved, whether the metric that was supposed to move actually moved — weeks or months after the delivery is complete and the team has disbanded.
Scope is what you build. Value is what changes. The castle is the scope. The princess is the value.
Many projects deliver the castle.
They never check whether the princess was in it.
The Three Castles
Toad’s line appears eight times in Super Mario Bros. — once after each world. Eight castles. Eight deliveries. Eight times the scope is met. Eight times the value is deferred.
This is not a coincidence in game design. It is the shape of how misaligned delivery actually works.
In organizations, the castles look like this:
The first castle: the feature that was requested but not the outcome that was needed.
A team builds exactly what was asked for. The requirements were clear, the acceptance criteria were met, the stakeholder signed off. But the stakeholder asked for a feature when they needed a behaviour change. The feature is in production. The behaviour has not changed.
The second castle: the system that works but nobody uses.
The platform was delivered. It functions as designed. The UAT passed. But adoption is at twelve percent six months after go-live, because the people who were supposed to use it were never part of defining what it needed to do. The system exists. The value does not.
The third castle: the transformation that was announced but not embedded.
The workshops ran. The framework was trained. The new process was documented. The leadership communicated the change. And three months later, the organization is running the old process with new terminology. The delivery happened. The transformation did not.
Three different projects. Three different domains. The same castle. The same absent princess.
Moving the Castle
There is a version of this problem that is even more damaging than the wrong castle.
The castle that moves.
Scope creep is usually framed as a risk to delivery — more requirements, more work, more time, more cost. This is true. But scope creep is also a symptom of something deeper: the victory condition was never clear enough to make requests refusable.
When a project has a precise definition of value — when the team can answer “what change in the world would mean we succeeded?” — a new request has a test. Does it bring us closer to that value? If yes, it deserves consideration. If no, it is a distraction with a good rationale attached.
Without that definition, every request is equally valid. Every stakeholder’s priority is a legitimate priority. Every new feature adds scope without asking whether it adds value. The castle grows. The princess remains wherever she was.
Without a victory condition, scope cannot be defended. Without a victory condition, every new request is another castle to find her in.
Approval Is Not Commitment. Commitment Has a Cost.
Everyone approved.
The business case was signed off. The requirements were validated. The design was reviewed. The steering committee gave the green light. At every checkpoint, the stakeholders said yes.
And yet the value did not arrive.
Approval is cheap. It costs nothing to agree in a meeting that a project is important, that the scope is right, that the budget is sufficient. Approval requires only presence and a signature.
Commitment has a cost.
Commitment means that when the project conflicts with something else — another priority, another budget request, another team’s roadmap — the stakeholder chooses the project. Commitment means making the people available, the decisions timely, the trade-offs explicit. Commitment means staying engaged when the delivery is at risk, not only when the update is positive.
Projects collect approval. They mistake it for commitment.
And then the castle is reached. Toad is waiting. And the princess — the actual value that required actual commitment to create — is somewhere else.
ARC: The Anatomy of the Quest
Core — The Princess
The princess is not a person. She is a purpose. She is the reason the castle exists.
She is the specific change in the world that the project exists to create — the customer behaviour that shifts, the operational cost that falls, the capability that becomes real, the experience that improves. She is why the castle matters.
Core asks: what must be true about this project for it to have been worth doing?
When the Core is clear, every scope decision has a test. When the Core is vague — when the princess is described as “improved efficiency” or “better customer experience” or “digital transformation” — the castle can be delivered without her in it, and no one will notice until months later.
Adaptation — The Route
Eight worlds. Each one different. Each one requiring a different approach, a different timing, a different response to what the terrain reveals.
Adaptation is not changing the destination. It is adjusting the route in response to what each world actually contains — without losing sight of which castle the princess is in.
Projects that adapt well change how they deliver. Projects that mistake adaptation for scope expansion change what they deliver, and in doing so change what they can actually reach.
Rejuvenation — The World Reset
After each castle, the world resets. New challenges. New patterns. New traps. What worked in World 3 does not automatically work in World 7.
Rejuvenation is the capacity to carry the learning from the previous delivery into the next — not the assumptions, not the same playbook, not the same scope definition. The learning.
An organization that reaches Toad eight times and does not ask why the princess was never there is not adapting. It is repeating.
Oracle. Labyrinth. Spartan Stand.
Oracle asks the castle question before the project begins.
Not: what will we build? Oracle asks: if we build this, will value actually be there? What evidence do we have that the princess is in this castle and not the next one? What are we assuming about the relationship between our delivery and the outcome we need?
Oracle does not wait for go-live to ask whether the project created value. It builds that question into every gate, every sprint, every decision to continue or redirect.
Labyrinth maps the distance between the delivery and the value.
The system that will be changed. The behaviours that need to shift. The dependencies between the output of the project and the outcome in the world. The other castles — the adoption plan, the change management, the operational embedding — that must also be reached for the princess to actually be found.
Labyrinth does not describe the castle you plan to deliver. It maps the full terrain between where you are and where the princess is.
Spartan Stand asks the value question every sprint.
Not: are we on track to deliver scope? Spartan Stand asks: is this sprint’s work still pointed at the princess? Has something changed — in the market, in the organization, in the user behaviour — that means the castle we are building no longer contains the value we are chasing?
If yes: redirect. If no: proceed with discipline.
Oracle identifies the right castle. Labyrinth maps the terrain. Spartan Stand ensures each sprint is still moving toward the princess and not just toward the nearest flag.
Find the Princess First
Every project team knows how to reach a castle.
Fewer ask which castle the princess is in before they start running.
The question is not whether your team can deliver. Most teams can deliver. Scope is manageable. Backlogs can be completed. Castles can be reached.
The question is whether the delivery will find the value — whether the castle you build is the one she is waiting in.
Before the backlog is built, ask what change in the world would constitute success.
Before the sprint begins, ask whether this work is pointed at that change.
Before the go-live is celebrated, ask whether the value is actually there — or whether Toad is waiting with the same quiet, apologetic announcement.
Thank you. But the princess is in another castle.
Delivery is not victory.
Value is not automatic.
The castle is not the destination.
The princess is.
Hat Sarsılmaz.
But only if we know which castle she is in.
Oracle identifies the right castle. Labyrinth maps the terrain. Spartan Stand ensures every sprint is still pointed at the princess.
Mytholagile — Epic on the Outside. Lean on the Inside.
Leave a Reply