Pull up any engineering team's sprint report and you'll find the same reassuring wall of numbers: PRs merged, tickets closed, story points burned down to zero. Everyone nods. The sprint "went well."
Then ask the harder question in the same meeting: what changed for the business because of any of this? Not what shipped — what changed. In most rooms, that question is met with silence, followed by someone pulling up the changelog as if it were an answer.
It isn't. A changelog tells you what the team did. It says nothing about whether any of it moved the thing your organisation actually needs to move. I've sat in enough of these reviews, across enough companies, to know this isn't a discipline problem or a laziness problem. It's a measurement problem, and it's baked into how most engineering teams — and most leadership teams above them — have been trained to think about progress.
Who's telling you this
I'm Maddy, Co-Founder and CEO of Worxmate. I've spent twenty years in strategy execution, ten of them specifically inside OKR implementations, coaching leadership and engineering teams across 50+ organisations — IT services, fintech, retail, energy, manufacturing — from a 70,000-person IT services organisation to a 100-person European fintech startup still finding its footing. I've watched the exact moment engineering leaders realise their sprint metrics have been lying to them, and I've watched what changes in the six months after they stop trusting those metrics blindly. This isn't a framework I read about. It's the pattern I see, repeatedly, in rooms full of very smart engineers who were never given a better way to answer "did this matter."
The number that feels like progress and isn't
Forty PRs merged is an output. It tells you the team was active. It does not tell you whether the product is more reliable, whether users are converting faster, whether the thing that was actually broken got fixed, or whether the team spent three weeks building something nobody asked for with genuine competence.
This is the trap with any output metric: it always goes up when people work hard, which makes it feel like a legitimate signal of progress. It isn't. It's a measure of motion. Motion and progress correlate often enough that most teams never notice when they've decoupled — until a quarter goes by, the PR count looked great the whole time, and the business is exactly where it started.
I ran a version of this exercise with a leadership team inside a 70,000-person IT services organisation. Every MBR showed green. Sprints closing on time, utilization healthy, dashboards full. Privately, every leader in the room admitted they had no real idea what was actually blocking the business from growing. The breakthrough wasn't a new dashboard. It was a live exercise where I handed them a wall of their own real goals and asked them to sort the ones that described what they'd done from the ones that described what had actually changed. Nobody sorted it correctly on the first pass. Not because they weren't sharp — because their entire professional training had taught them that finishing things is the same as improving things.
Engineering teams inherit this same blind spot, just wearing different vocabulary. "Ship the redesigned onboarding flow" feels like a real goal because it's specific and has a clear finish line. It isn't an outcome. "Reduce time-to-first-value for new signups from 9 days to 3" is an outcome — it tells you exactly what should be different in the world once the work is done, and it tells you immediately whether the redesign actually worked or just shipped.
Most sprint goals never make that distinction. They're written as deliverables because deliverables are easy to scope, easy to estimate, and easy to report as "done." Outcomes are none of those things, which is exactly why teams avoid writing them — and exactly why avoiding them is the reason so much shipped work produces so little measurable change.
The pattern behind every "why doesn't this feel like progress" conversation
Across every organisation I've coached, the goals that survive a real outcome Vs output sort tend to break the same way. A goal like "migrate the service to the new infrastructure" is output — necessary work, sometimes urgent work, but it says nothing about impact on its own. "Reduce P1 incident response time from 40 minutes to under 10" is the outcome that migration was supposed to produce. If nobody wrote that second sentence down, the team can complete the migration flawlessly and still have no idea whether it was worth doing.
I've watched teams complete 80% of their stated sprint or quarterly goals and produce zero material change in the business, because the goals were never outcomes to begin with. That statistic should be more alarming to engineering leaders than it usually is, because completion rate is the number everyone reports upward, and it is the least meaningful number in the room. A team can be extremely good at finishing the wrong things.
One completed OKR is worth more than five written ones — because the five were never outcomes to begin with.
This is where the "did any of them matter" question earns its place in a retro, not as a gotcha, but as the only question that actually predicts whether the next sprint will be better than this one. Ask it enough times and teams stop defaulting to "what can we finish" and start asking "what needs to be true when this ships." That's a small linguistic shift with a large downstream effect — it changes what gets prioritized before a single line of code is written.
I've seen the same pattern play out with a Product Lead and an Account Executive at a European fintech startup, roughly 100 people, generating revenue but still learning how to set goals that actually drove growth. When I asked the CEO and CPO what the one big thing was that needed fixing, the answer was product demo experience. The instinctive next step for most engineering-adjacent teams would have been a backlog of demo-flow tickets — an output list. Instead, we pushed the goal through a sequence of "so what" questions: if you fix the demo flow, so what? What happens next? The answer, eventually, was conversion. So the Key Result got written around conversion, not around the number of demo-flow tickets closed — and the Product Lead and Account Executive were made jointly accountable for it. Neither function could quietly finish their half and call it done. That single structural change — co-ownership of one outcome instead of two disconnected output lists — did more for that team's actual results than any sprint process change would have.
The framework: sort before you sprint
The mechanism I use with Product Head is deliberately simple, because complexity is exactly what causes teams to abandon the practice after one cycle. Before a sprint or a quarter is planned, take every candidate goal and run it through one question: if this ships perfectly, what number, behavior, or state changes as a result — and how would we know?
If the honest answer is "the code exists" or "the ticket is closed," it's output. Keep it if it's necessary work, but don't let it stand alone as a goal — pair it with the outcome it's meant to produce. "Migrate to the new queue system" pairs with "reduce message processing failures from 2% to under 0.1%." The first is the work. The second is the reason the work matters, and it's the only one worth putting in front of leadership.
If the answer names something that changes in the world — a metric moves, a user behavior shifts, an incident class disappears — it's an outcome, and it's the goal worth protecting when priorities get squeezed mid-sprint.
This is the same discipline behind what I call the Execution Maturity Rate — the percentage of leaders and team leads in an organisation who can independently write a genuine outcome-driven goal, without coaching, without a template, without someone reviewing it first. In a typical first cycle, across every industry I've worked in including engineering-heavy organisations, that number sits between 5% and 15%. It's not a competence problem. Almost nobody starts good at this, because nothing in a typical engineering career trains you to think this way — sprint planning trains you to scope and estimate, not to define what success looks like in outcome terms. In teams that practice this consistently for 12 months, the number climbs to 30–40%.
That climb is the actual ROI of getting serious about outcome-thinking. Not "did we hit our sprint goals" — that number can look excellent while the roadmap drifts. The real question is how many engineers and leads can look at a business problem and independently frame the outcome it needs to produce, without anyone walking them through it. You can read more on how this connects to broader goal alignment across teams — the same output-versus-outcome gap that shows up inside a single sprint shows up at the cross-team level too, just with higher stakes.
A few rewrites make the pattern concrete, because it's easier to spot in someone else's backlog than your own:
- "Refactor the auth module" becomes "Reduce auth-related support tickets from 40/week to under 10." The refactor might still be the right work — but now there's a number that tells you whether it was.
- "Add caching layer to the API" becomes "Cut p95 API response time from 800ms to under 200ms." Same engineering effort, but now the team knows what "done and working" actually means, versus "done and merged."
- "Roll out feature flags across the platform" becomes "Reduce time-to-rollback on a bad deploy from 40 minutes to under 5." The tooling is the same either way. The goal now tells you why you're building it.
Notice none of these rewrites change the actual engineering work. They change what the team is accountable for once the work ships — the difference between "we built the thing" and "the thing did what it was supposed to do." That distinction is invisible in a PR count and unmissable in a retro that asks the right question.
One more signal worth watching, borrowed from the pattern I look for in the first week of any new engagement: how much friction the team hits translating this into practice. If engineers are burning excessive time each cycle just figuring out how to phrase a goal as an outcome, that's not a sign the team lacks discipline — it's a sign the practice hasn't been coached in, and it will quietly get abandoned under the next deadline crunch unless someone addresses the friction directly rather than just asking for more effort.
What changes six months in
The teams that internalize this don't necessarily look different from the outside. Same standups, same sprint cadence, same tools. What changes is the conversation in planning and in retro. Someone asks "what happens if we ship this and nothing changes" before the ticket gets written, not after. PR descriptions start referencing the metric they're meant to move, not just the change they made. Retros stop being a list of what got done and start surfacing which finished work actually produced the expected shift — and which didn't, which is often the more useful finding.
None of that shows up in a PR count. It shows up in whether the next sprint's priorities are noticeably sharper than the last one's, and in whether a team lead can explain, in one sentence, why a piece of work mattered — not just that it shipped.
Bottom Line
Forty PRs is a fact about your team's activity. It is not evidence about your team's impact, and treating the two as interchangeable is how organisations end up with busy engineering teams and stalled roadmaps at the same time. The fix isn't better sprint tracking. It's asking, before the work starts, what should be true afterward — and refusing to call a goal finished until that question has an answer.
If you want to see where your own team's current backlog falls on that output-versus-outcome line, Worxmate's OKR platform is built to catch output-dressed-as-outcome goals at the point of writing, with AI-assisted quality scoring before they ever make it into a sprint or quarterly plan.
But if the honest answer is that your engineering leads have never actually been coached through making this distinction — that the tool isn't the first problem — that's a more common starting point than most teams admit. That's what Worxmate's OKR consulting engagements exist for. The software is the infrastructure. The coaching is the capability. You need both, and in the right order.
Top comments (0)