Most teams are busy.
Sprints are full. Backlogs are packed. Roadmaps look impressive.
And still… the impact is often unclear.
That’s the trap: we celebrate output, while we hope for outcome.
Output is what we deliver
Output is the visible result of work.
- Features shipped
- Stories completed
- Tickets closed
- Releases done
- “We built it” ✅
It’s concrete. Easy to measure. Easy to report.
And yes: output matters.
But output is not the same as value.
Outcome is what changes because of it
Outcome is the effect you create.
- Customers can do something faster
- Error rates drop
- People stop calling support
- Conversion goes up
- Trust increases
- A process becomes easier
- “It actually helped” ✅
Outcome is maybe harder to measure.
But it’s what you really want.
The confusing part: both feel like success
Here’s the problem:
Output gives quick dopamine.
Outcome takes time, learning, and often some discomfort.
So output wins by default.
You finish a sprint and look at the board:
“Done, done, done. Great sprint!”
But if nobody uses the feature…
if customers still complain…
if the real problem is untouched…
Was it a great sprint?
A simple model that helps
In my workshop I use a simple “flow” that many organisations recognize:
Product Vision → Product Goal → Sprint Goal → Product Backlog Items
At the bottom we have lots of items (PBI’s).
That’s where output lives.
But higher up — sprint goal, product goal, product vision — that’s where outcome and impact show up.
If you only look at the bottom, you might optimise for speed.
If you look at the full chain, you optimise for purpose.
Another view: the Logic Model
The Logic Model (W.K. Kellogg Foundation) explains it nicely:
Resources → Activities → Outputs → Outcomes → Impact
It’s a reminder that:
- Just doing activities doesn’t mean you create outcomes.
- Just delivering outputs doesn’t mean you create impact.
Teams often stop at “we delivered the output”.
Stakeholders care about the last two boxes.
Football makes it painfully obvious
A fun example from one of my workshop decks:
You can measure a lot during a football match:
goals, assists, shots on target, accuracy…
All interesting.
But the match is decided by… the final score.
That’s the outcome. For this day.
(I don’t want to overcomplicate it, but if you look at the bigger picture, like the national league, this final score is just output. The outcome will be clear at the end of the season.)
You can run the most kilometers and still lose 0-1.
Output: we worked hard
Outcome: we won (or didn’t)
This is what happens in organisations too.
The danger of output-thinking
Output-focus creates some classic behaviours:
- More items = more success
- “Just keep the team busy”
- Shipping becomes the goal
- Roadmaps become a checklist
- Success becomes a slide deck
How to shift the conversation (without becoming annoying)
You don’t need to turn everything into “OKR theatre”.
A small shift can already help.
Try these questions:
- What do we want to be different after this?
- How do we know this worked?
- What would we see in customer behaviour?
- If we deliver this, what problem disappears?
- What happens if nobody uses it?
They sound simple.
But they change everything.
A practical way to start next sprint
Here’s an easy approach that works well in real teams:
- Define the Sprint Goal as an outcome
Not “build X”, but “enable Y”. - Choose 1–2 signals you can observe
Not perfect metrics. Just signals.
Example: fewer clicks, fewer calls, faster flow. - Deliver output as a hypothesis
“We think feature X will lead to outcome Y.” - Check what happened
Not to blame. Just to learn.
This turns Scrum into what it should be:
a learning loop.
Output is the effort. Outcome is the point.
Output keeps the engine running.
Outcome tells you if you’re heading in the right direction.
So yes, deliver.
But don’t just count what you shipped.
Measure what changed.
Because at the end of the day, nobody hires a team to be busy.
They hire a team to make things better.
