Last updated: October 12, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
Scope creep is work added or swapped in after a project is committed, and a mid-sprint priority change costs far more than the new work, because the team pays to stop, replan, reload context, and repair what it abandoned. On my worksheet, a six-engineer team taking two swaps a sprint loses about $277,000 a year. That is roughly 1.4 fully loaded engineers doing nothing but turning the wheel.
The decision took one sentence in a Thursday leadership sync. Unwinding it took most of a quarter.
We were nine days into a two-week sprint on a loan-servicing platform, and the team was close on an escrow analysis rewrite that had been the top priority for six weeks running. Then a partner meeting went well. Very well. Somebody senior said the broker portal needed to be “in front of them by month end,” three of my six engineers were moved over that afternoon, and nobody in that room thought of it as an expensive decision. It did not feel like one. It felt like responsiveness.
The demo happened. The partner liked it, then signed nothing for five months. The escrow rewrite came back three sprints later with two branches that would not merge cleanly, a test suite that had drifted, and one engineer who spent most of a week rebuilding her mental model of a calculation she had understood cold six weeks earlier. Nobody connected it back to Thursday. Nobody sent an invoice for any of that. There is no line for it in any budget I have ever seen.
That bill is what this piece is about. Not whether priorities should ever change. They should, sometimes, and I will get to when. This is about who pays, how big the number actually is, and how to put it in front of the people who keep running it up without becoming the leader who says no to everything.
If you have read the Clarity Stack, you already know where this lives. Layer 2. Priorities that are not written down where the team can see them. I covered the fix for that layer, one written priority with an owner and a date, in the case for keeping engineering priorities in writing. Writing it down is necessary. It is not sufficient. A written priority that gets rewritten every Thursday is still whiplash, just better documented. What changes leadership behavior is the price tag.
Scope Creep, Reprioritization, and Whiplash Are Three Different Problems
Scope creep is the uncontrolled growth of a project’s scope after it has been committed, through added features, expanded requirements, or swapped-in work, without a matching change to time, budget, or staffing. Roadmap whiplash is its repeated, reversing form, where priorities change direction often enough that work gets started, shelved, and restarted.
It is common. PMI’s 2018 Pulse of the Profession found that 52 percent of projects completed in the prior twelve months experienced scope creep or uncontrolled changes to scope, up from 43 percent five years earlier. That covers projects across industries, not only software. Roughly half. A coin flip.
The term gets used loosely, and the looseness is part of why leaders shrug at it. “A little scope creep” sounds like holiday weight gain. Mildly embarrassing, mostly harmless. It is neither. The things people lump under that heading cost very different amounts, and you have to be able to tell them apart before you can argue about any of them.
| What happened | What it looks like in the sprint | What it costs | The right response |
|---|---|---|---|
| Scope creep (an addition) | A ticket grows, or “while you’re in there” work lands on top of the plan | The new hours, plus whatever quietly slips off the end of the sprint | Trade it for something of equal size, in writing |
| Reprioritization (a swap) | Work in flight is paused so different work can start | The new hours, plus stop and restart costs on everything that got paused | Allowed occasionally, logged every time, owned by a name |
| Roadmap whiplash (a reversal) | The paused work comes back, or the new work is dropped before it ships | Both sets of switching costs, plus work that never ships at all | Treat it as a leadership problem, not a planning problem |
| A genuine interrupt | A Sev 1 incident, a regulator’s deadline, a security patch | Real, and usually unavoidable | A separate lane with reserved capacity, so it never counts as a swap |
That last row matters more than it looks. When incidents and regulatory deadlines share a queue with “the CEO had an idea at dinner,” every change looks equally legitimate, and you lose the ability to push back on any of them. Split them. The incident lane is not up for negotiation. Everything else is.
The Bill Nobody Sends
Here is the worksheet I use. It is not elegant. It does not need to be. Its only job is to turn “the team seems frustrated” into something a CFO would recognize as a number.
Start with what an engineer-hour costs. According to the Bureau of Labor Statistics, software developers earned a median annual wage of $135,980 in May 2025. Wages are not the whole cost of a person, though. June 2026 employer compensation cost data from BLS shows wages and salaries at 68.5 percent of total compensation for full-time private industry workers, with benefits making up the rest. Divide the median wage by 0.685 and you land near $198,500 a year in employer cost, or about $95 an hour across 2,080 paid hours. Your number is probably higher. Mine always was. Use yours. Finance has it.
Now take one mid-sprint swap on a six-engineer team, where three people get moved and two pieces of in-flight work get parked. These are the line items I have watched show up, again and again, at roughly that size.
| Line item | Who pays it | Hours | Cost at $95/hour |
|---|---|---|---|
| Replanning and re-estimating the sprint | Six engineers, the product manager, and the engineering manager, for one hour | 8 | $760 |
| Unloading and reloading context | Three engineers, twice each (out and back), about three hours per switch | 18 | $1,710 |
| Repairing parked work when it resumes | Rebasing stale branches, re-review, re-running tests that drifted, about 12 hours per parked item | 24 | $2,280 |
| Ripple to adjacent teams and stakeholders | Dependent teams re-sequencing, status updates rewritten, the demo moved | 6 | $570 |
| Total per swap, before the new work itself | 56 | $5,320 |
Fifty-six hours. For one swap. And look at what is missing from that table, which is the new work. The broker portal cost whatever it cost, and that cost was at least visible, because somebody estimated it. The fifty-six hours are the part nobody estimated at all.
Now run it for a year. Two swaps a sprint is ordinary in a company that thinks of itself as responsive, and over 26 two-week sprints, that comes to 52 swaps, 2,912 hours, and about $277,000 of fully loaded time spent stopping and restarting. A six-person team has 12,480 paid hours a year. You just handed almost a quarter of them to turning the wheel. That is about 1.4 engineers whose whole job, if you could see it on an org chart, is starting over.
Nobody would approve that req. Plenty of leaders approve it anyway, two decisions a sprint, one hallway conversation at a time.
My hour estimates are not research. They come from watching this happen at mortgage-tech and fintech shops of about this size, and they could be off by a third in either direction. Fine. Cut every line by a third and you are still paying for most of an engineer. The worksheet is not about precision. It is about showing that the number exists and is never zero. Zero is exactly what the person asking for the change is assuming.
What the Spreadsheet Cannot See
Context reload is the line people argue with most. Fair. So look at what is actually known about it.
Chris Parnin and Spencer Rugaber analyzed 10,000 recorded programming sessions from 86 programmers, plus a survey of 414 more, and published the results in Software Quality Journal. Only 10 percent of sessions had programming activity resume within a minute of an interruption. Ten percent. Only 7 percent involved no jumping to other parts of the code before editing started again. Programmers do not drop back into a task. They climb back in, reading and tracing and reconstructing what they knew before somebody moved them.
Their study looked at ordinary interruptions. A reprioritization is worse. It is not a tap on the shoulder. It is a different problem for days or weeks, followed by a return to a codebase that kept moving without you.
Sophie Leroy, now a professor at the University of Washington Bothell, named the mechanism in 2009. Attention residue. Part of your attention stays on the task you left, especially when you left it unfinished, and the next task gets done with whatever is left over. An engineer pulled off the escrow work at the 80 percent mark does not leave it behind. She carries it into the broker portal, does that work a little worse, then carries the portal back into escrow three sprints later.
Then there is a finding that explains why leaders rarely believe any of this. In a controlled study published at CHI 2008, Gloria Mark, Daniela Gudith, and Ulrich Klocke found that people interrupted mid-task actually finished sooner, and their work was no worse for it. What went up was everything a burndown chart cannot show. Stress. Frustration. Time pressure. Effort.
Your engineers do the same thing. Quietly. That is exactly the problem. From the leadership chair, a team that absorbs whiplash and still hits most of its dates looks fine. Under the hood it is running hotter every sprint, and the bill arrives later, somewhere you are not looking. A resignation. A senior engineer who stops raising risks in planning because the plan will change anyway. Estimates that quietly inflate, which I wrote about in treating sprint estimates as informed commitments.
Google’s DORA research lands in the same spot by another route. Its 2024 report found that unstable organizational priorities reduce productivity and raise burnout, and that the effect held even on teams with strong leaders and good documentation. That second half is the part executives tend to skim past. Do not let them.
Why Smart Leaders Keep Doing It
Because the change is free to the person making it.
That is the whole mechanism. The executive who moves three engineers pays nothing at the moment of the decision. No budget line moves and no approval is required. The cost lands two to six weeks later, on other people’s calendars, spread across fifty small delays, missed handoffs, and re-reviewed pull requests that nobody ever traces back to the Thursday sync where it all started. Any system where the person deciding never sees the invoice will overspend. Cloud bills worked exactly this way before anyone started tagging resources to owners, and most of us were the ones overspending.
I have done it. More than once. Early in my time running a lending platform team, I pulled two engineers onto a pricing-engine fix because a sales VP told me a deal depended on it. The deal did not depend on it. I found that out a month later, by which point the work those two had dropped had already slipped a quarterly regulatory reporting date that actually did matter, and that one came with a phone call from compliance. I did not need a better process. I needed to ask one more question before I moved anybody.
There is a quieter reason, too. Responsiveness looks like leadership. “We will have that by month end” sounds decisive in a partner meeting, and “let me check what it displaces” sounds like stalling. Leaders get rewarded for the first sentence in the room and almost never get billed for it afterward.
How to Push Back Without Becoming the Department of No
Do not argue about whether the new priority matters. You will lose, and sometimes you will deserve to, because sometimes it does. Argue about the cost. Nothing else. This is the sequence I use.
- Bring the invoice, not the complaint. Fill in the worksheet with your own team’s numbers once and keep it current. “The team is frustrated” is a feeling, and executives are trained to discount feelings. “$5,300 a swap, and we took eleven last quarter” is a budget line. Different conversation.
- Keep a whiplash log for one quarter. One row per mid-sprint change, with the date, who asked, what came in, what went out, and whether the parked work ever came back. That last column is the one that moves people. When I kept one at a mortgage-tech company, four of the eleven things we had paused never resumed at all, so every hour already spent on them was simply gone.
- Give change a budget, the way SRE teams give reliability an error budget. One swap per sprint goes through with no meeting. A second one requires the person asking to write down what dies to make room. A third in the same sprint goes to whoever owns the roadmap, with the log attached. Titles do not exempt anyone.
- Freeze the last three days of every sprint. Boring. Works.
- Reserve 15 to 20 percent of capacity for the incident lane, and protect it. Once real emergencies have a home, “this is urgent” stops being a password that skips the budget.
None of this blocks anything, on purpose. A leader who blocks every change gets routed around within a month, and then the changes arrive as direct messages to individual engineers, which is worse than the whiplash you started with. The budget lets the change happen. It just makes the person asking hold the receipt. If nobody can say who is allowed to spend that budget, you have a different gap, and the decision-rights map is how you close it.
Not sure whether whiplash is your main problem or a symptom of a different one? Run the three tests in the free engineering velocity assessment first. From the outside, a broken Layer 1 and a broken Layer 2 can look almost identical.
The Conversation With the CEO
Most of the whiplash I have seen started at the top. Not maliciously. The CEO sits closest to customers, investors, and the board, so new information lands there first, and acting on new information is the job. Fair enough.
So do not make it a conversation about discipline. Make it a conversation about money, in units the CEO already uses. I laid out that translation for board meetings in communicating engineering work to executives, and it works one-on-one just as well. Something like this.
“Last quarter we changed direction mid-sprint eleven times. Each change cost about $5,300 in stop-and-restart time before any of the new work began, so call it $58,000. Four of the things we paused never came back. I am not asking us to stop changing priorities. I am asking that the second change in any sprint come with a name on what we drop, so we both know what it cost.”
I say “show me the data” a lot. This is the version where I hand it over first. A CEO shown that number usually does one of two things. The swap rate falls on its own within a quarter, or you learn that the CEO genuinely believes the market moves faster than your sprint length. That second outcome is a different conversation, and a much more useful one.
When the Whiplash Is Telling You Something
Sometimes the priorities really are moving that fast. A rate move changes mortgage volumes in a week. A competitor ships. A regulator publishes a rule with a 90-day clock. It happens. If the market moves faster than your planning cycle, fighting every change is the wrong fight. Shorten the cycle instead. One-week sprints, or a flow system with real work-in-progress limits, lower the price of each individual change, because there is simply less work in flight at the moment the change arrives, and less to repair afterward.
And sometimes the whiplash is really a staffing gap. The usual shape goes like this. One senior engineer is the only person who understands the payments ledger, so every urgent request routes through her, so each one pulls her off whatever she was doing, so everything she touches gets parked. A change budget will not fix that. A second person who can hold the ledger will.
The tell is where the swaps land. Look at the log. Spread evenly across the team, they point to a prioritization problem. Landing on the same two or three people every time, they point to a bench problem, and the engineering velocity diagnostic exists to separate those two before you spend money on the wrong one. Run the slow-versus-tired test alongside it, because whiplash shows up in both kinds of org.
When it is a bench gap, KORE1 is who I point people to, with a bias worth naming, since they publish my work. They have been doing this since 2005, in more than 30 U.S. metros. IT roles average 17 days from kickoff to hire, and 92 percent of their placements are still employed there twelve months on. That retention figure matters most here. The second person who can hold the ledger only helps if they are still around next year. Most of those searches belong on a direct hire basis, because what you are paying for is knowledge that should outlast any contract, and KORE1’s software engineer staffing team runs them.
What Leaders Ask Me When the Roadmap Keeps Moving
Isn’t Some Scope Creep Just Agile Working the Way It Should?
Changing the plan between sprints is agile working as designed, while changing it inside a sprint without trading anything out is scope creep, and the difference is whether anyone priced the change.
The Scrum Guide draws the line plainly. During a sprint, no changes are made that would endanger the Sprint Goal. The team can sharpen scope with the Product Owner and renegotiate it as it learns, and only the Product Owner can cancel a sprint. Reordering belongs in the backlog. Between sprints. Teams that cite agile to justify mid-sprint churn usually have it backwards.
How Do I Calculate the Cost of Scope Creep on My Own Team?
Multiply your fully loaded hourly rate by the hours each change burns on replanning, context reloading, repairing parked work, and coordinating with other teams, then multiply by the number of changes you absorbed last quarter.
Get the rate from finance, not a salary survey. If they will not share it, the median wage divided by 0.685 is a defensible stand-in. Count changes from your ticket history, meaning anything added to an active sprint after day one and anything pulled out of one. It takes an afternoon. The first time I ran it, the total was big enough that I assumed I had made an arithmetic mistake and spent an evening looking for it. There was no mistake.
Scope Creep vs. Feature Creep: Does the Difference Matter?
The difference barely matters for cost, because feature creep is one kind of scope creep, the steady addition of features to a product, while scope creep also covers expanded requirements, new deliverables, and swapped-in work.
For product strategy, the distinction is useful. For the bill? Irrelevant. A feature dropped into day six of a sprint costs the same stop-and-restart hours as any other swap.
Should We Ban Priority Changes Mid-Sprint Entirely?
No, because a total ban pushes urgent requests into side channels and direct messages, which ends up costing more than the whiplash you were trying to stop.
Reserve capacity for genuine interrupts, budget the rest, and make the second change in a sprint expensive to ask for. A rule nobody can follow gets followed by nobody. I have tried.
The CEO Is the One Changing Priorities. Now What?
Bring the CEO one quarter’s whiplash log with a dollar figure attached, and ask for a named trade on the second change in any sprint instead of asking for fewer changes.
I used to think this conversation took courage. It mostly takes preparation. Receipts win. A VP of engineering who walks in with “the team is burning out” gets sympathy and nothing else. One who walks in with eleven dated rows, a per-swap cost, and four abandoned projects gets a decision. CEOs also respond well to being given a role in the fix instead of being cast as the cause of the problem, which is why the ask is a trade and not a freeze. Give them a lever, not a lecture. And if the answer is still “the market is moving too fast for two-week plans,” believe them for a quarter, shorten your cycle, and see whether the log agrees.
Realistically, How Often Is Too Often to Reprioritize?
More than one unplanned swap per sprint, sustained over a quarter, is my working threshold for whiplash on a team of five to eight engineers.
Below that line, the cost is real. Absorbable, though. Above it, watch for three second-order signals. Estimates creeping upward, parked work that never resumes, and senior engineers going quiet in planning. If you see two of the three, you have crossed the threshold, whatever the count says.
Send the Invoice
A priority change is a purchase. Most organizations make it without looking at the price, because the price shows up weeks later on somebody else’s calendar. You do not have to stop buying. You need a receipt. Fill in the worksheet, keep the log for a quarter, and put the number in front of whoever keeps asking. Then let them decide, knowing what it costs. That is all pushback really is.
If you would like a second pair of eyes on the worksheet for your own team, or you just want to compare whiplash logs, DM me on LinkedIn. And if your log keeps pointing at the same two engineers, bring that gap to a KORE1 engineering recruiter.
Related reading: The Coordination Tax: Brooks’s Law and Why Adding Engineers Made Your Team Slower.
