The Real Cost of a Bad Sprint: How to Calculate Engineering Rework

There's a number buried in your team's sprint history that you've never bothered to compute.

It's the amount of money spent building the wrong thing.

Not bugs, not technical debt. Product builds that went smoothly from ticket to ship but solved the wrong problem.

Most teams recognise this happens from time to time. Almost no teams know how much time it takes, or how much money it costs when it happens.

If an engineer is typing away on their keyboard, they're by default considered "building the product". Whether they're building the first version of the product or the fifth isn't tracked or reported anywhere.

Your sprint board doesn't have a "rework" column. You don't collect metrics on "what percentage of engineering time is spent on fixing translation errors". It all just gets absorbed into development velocity and nobody thinks twice about it.

Which is why most founders severely underestimate how much rework is happening on their team. Things are getting done. Everyone's working hard. Velocity looks good!

Except it's not really velocity if a large percentage of your team's activity is "redoing work that satisfied the original spec but didn't actually solve the customer's problem."

To build that number out, let's assume:

• —The average engineer at your seed-stage B2B SaaS company costs between £60k–£100k per year — salary plus employer taxes and benefits. We'll call it £80k for math's sake.
• —That's about £385 per day, or £1,925 per five-day sprint week.
• —A three-person team costs you £5,775 per week to employ fully.

Now think about how much of that team's time is spent on rework — duplicate builds caused by underspecified tickets that missed the customer's intent — in a typical sprint.

Engineering leads when forced to actually reckon with this number say between 10% and 25%. It's rarely lower than 10%.

At 15% rework for a team of 3 engineers:

• —£866 / week
• —£3,464 / month
• —£41,568 / year

That's bad tickets, not bad engineers. Not poor process, but unavoidable failure to extract granular detail from customer requests.

A five-person engineering team incurs a £70,000 cost at the same rework rate. And your team probably has that number right now in your sprint history. Quietly.

You don't need detailed reporting to get a ballpark number. You need to answer three honest questions about your last ten sprints.

• —How many tickets required follow-up for scope clarification after being pulled into a sprint? The ticket that an engineer started working on, realised was underspecified, and then had to stop working on until they got more information. Count these tickets.
• —How many tickets that felt "complete" at the time were revised, reopened or followed up by another ticket within two sprints? The ticket that went through review and shipped but then came back because it didn't actually do what the customer needed done. Count these tickets.
• —How many hours did your team spend last month discussing things that should have been clarified before the sprint began? Count the hours — especially conversations that were only resolved by making an assumption and moving forward.

Got your numbers? Multiply by your team's fully loaded hourly cost and you have your cost of rework.

Teams that do this exercise for the first time are often surprised by how quickly it adds up. Most ticket discrepancies aren't expensive on their own. It's the frequency — the steady drip of tic-then-fix slowly eating away at your week.

This number isn't inclusive of how rework affects everything else.

• —It stalls your products. Every sprint spent building the wrong thing is a sprint not spent building towards your roadmap. The opportunity cost of a bad sprint is not only the labour you spend on it but also the value of the feature that should have been delivered instead.
• —It breaks down trust between engineers and PMs. Engineers who regularly build things that are sent back for revision stop trusting tickets. They start padding estimates, asking more questions before starting, playing it safe. Rational responses to a frustrating problem — but they don't get features shipped faster.
• —Delayed product means delayed customer outcomes. The customer who filed the original ticket is still experiencing their problem while the team builds the wrong thing and then the right thing. In a competitive business, delayed resolution carries retention costs.
• —It lowers your true roadmap velocity. If 15% of your engineering time is spent correcting course, you'll deliver features more slowly than you think — not just because estimation is hard, but because you've lost time correcting errors that come from a lack of specificity at the beginning of the feature lifecycle.

Bad tickets aren't caused by bad engineers or uncommunicative customers. Bad tickets are a failure of translation.

Here are the steps that lead to that 15% rework number:

• —A customer describes a problem in their own words. They aren't being purposely vague — but they describe the frustration, not the solution.
• —A founder or PM turns that request into a ticket. That translation routinely gets done in 10 minutes or less. Decisions get made about what was explicitly asked for and what could use improvement.
• —An engineer makes assumptions about the things that didn't get specified. They're reasonable assumptions — probably line up with what the PM thought when they wrote the ticket.
• —Something ships that everyone agrees works, but nobody is actually using. Either it gets reverted because it didn't satisfy the underlying problem — or worse, it sits there, and a new ticket gets filed.

The place to fix bad tickets isn't at step 4. By the time engineers are making assumptions, something has already gone wrong. Start catching mistakes at step 2 — reduce ambiguity before the ticket reaches the engineer.

Let's say you take your team's rework number from 15% down to 5%.

• —Current annual rework @15%: £41,568
• —New annual rework @5%: £13,856
• —Yearly capacity recovered: £27,712

That £27k isn't cash. It's capacity. Hours your team spends fixing ambiguity rather than building what customers actually need. Features that ship in 3 sprints instead of four. A roadmap that doesn't feel sluggish.

Scaling your team by improving translation accuracy doesn't need to cost anything. But once you start measuring that number you will never look at sprint velocity the same way.

Customer retention post-shipment: did the feature you just shipped solve the problem your customer originally reported?

If you're not tracking this number you should be. When teams start measuring how many features actually solve the problem they're aimed at, they see two things. First comes mild shock:

"It's way lower than we think."

There's an assumption that because "we shipped it" means "we solved the problem". Too often that's not the case. And most of that gap can be attributed to things getting lost in translation at the ticket-writing phase — important details, expected outcomes, or user context that nobody knew to define.

Find where those gaps are happening on your team and you'll find where your rework dollars are going. Almost all of it is recoverable.

Bad tickets are wildly expensive. Not "we should write better tickets" expensive. £40k/year expensive for your three-person team.

Money that passes through your sprint history as hidden costs — extra meetings, clarifications, tickets reopened and fixed. Money that accumulates into missed roadmap items, mistrust between PMs and engineers, and customers who churn because you took twice as long to solve their problem as you should have.

The place to stop bad tickets isn't when an engineer starts work. It's much earlier than that.

Specc is built to catch ambiguities before they become tickets — turning raw customer feedback into developer-ready specs with clear acceptance criteria, flagged open questions, and defined scope.

Try Specc free at speccapp.com