When Scrum Breaks Down
How we dropped sprint commitments and sped up delivery
The sprint failed again. The target wasn’t reached—not even close.
Critical production issues pulled half the team away from sprint goals. Tickets from the previous sprint failed QA and were reopened. User stories were dramatically underestimated—what looked like a two turned out to be five, and fives turned into eights.
We tried cutting the number of user stories, but then there were three or four stories for seven developers. The vicious loop continued. The team felt demotivated, failing to hit the sprint goal again and again. Half a day of planning and refining—for this.
I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs. This is the story of how we replaced Scrum with something that actually works for our team.
The Root Cause
The core problem was always the same: our estimates were wrong because our understanding was incomplete. The technical planning done during sprint planning sessions wasn’t enough. The system was already large, and no one knew or remembered all the details. Something estimated at 5 points could, in practice, turn into twenty or more.
In Scrum, sprints are supposed to be timeboxed chunks of highly effective, focused work. However, imprecision in estimates and frequent interruptions caused delays. As the team was under constant pressure to deliver, there was never time to resolve technical debt or automate repeated requests. So, in the next sprint, the team dealt with the same requests and the same bugs caused by the same technical debt.
It felt beyond frustrating. But it wasn’t anything new.
Early in my career, I was indoctrinated into agile ways of working—which meant Scrum. The system felt logical: estimate the work, deliver an increment, adjust, repeat.
Unfortunately, it didn’t work. One sprint after another failed.
Something needed to change.
What We Changed
We didn’t switch to a textbook framework. We simply dropped sprint commitments and moved to weekly prioritization with continuous delivery.
We kept things that worked and dropped the ones that didn’t. Instead of delivering story points and trying to reach the sprint goal, we concentrated on delivering business value and building sustainably.
From our Scrum-by-the-book, we kept dailies and retrospectives. Planning was replaced by a weekly check-in meeting.
How It Works Now
We replaced estimates and sprint planning with planning workshops, weekly check-ins, and internal RFCs.
In planning workshops, the team discusses business cases and high-level technical approaches. Once everyone understands the bigger picture, team members go deeper by writing RFCs and doing spikes.
Weekly check-ins happen every Friday. The PM brings a draft priority list and discusses it with the team. The team can suggest adding technical items or challenge the priorities. By the end of the check-in, the final list for the next week is ready.
The key difference from sprint planning is that there is usually no commitment required. Priorities are simply the most important things from a business and technical perspective: something the team wants to release as soon as possible, a flaky test that blocks work and needs fixing, or a recurring internal request worth automating.
Here’s the agenda we use for the weekly check-in:
What was done this week (what shipped, what moved forward, what got stuck)
Next week’s priorities (draft list from PM + team adjustments)
What we aim to release next week (no commitment, just an intention)
What QA needs to test (what’s ready, what’s coming, any risks)
What we need from PM next week (user stories, prototypes, decisions, clarifications, stakeholder alignment)
Questions (open items, risks, dependencies)
To be fair, there are occasional time-bound deliveries, like important client demos, but these are rare for us. The majority of work is managed as a priority list, not a sprint promise.
Daily meetings are the real heartbeat of the team. Early on, the team decided to keep dailies as a touch point for a primarily remote team (more on this here). But now the team doubled down on collaboration and resolving blockers.
Some daily meetings are short—only 10 minutes—and some can take half an hour or more. During the daily round, team members raise “after-daily topics” and say who from the team they need for that topic. After the updates round is over, after-daily topics are addressed in smaller groups.
Another meeting the team has kept is the retrospective. It has been a major engine for team development. It helped us surface and address technical and organizational issues. The team is encouraged to speak openly about problems and come up with actions, so the change is actually implemented. On the other hand, the team is discouraged from complaining without taking any action.
We stopped doing sprint reviews. Instead of demoing and getting feedback bi-weekly, we moved to continuous releases. Every time something is ready, the team can demo it internally, get feedback, adjust, and release.
What Improved
Almost immediately after abandoning Scrum, we started addressing the most problematic technical debt and automating recurring internal requests. As bugs were fixed and automation improved, interruptions became less and less frequent.
In the beginning, on a bad week, more than half of the team was putting out fires. Nowadays, it is usually just one person who monitors the system and responds to critical issues while still doing normal work.
As interruptions decreased and focus time increased, delivery sped up significantly. Before, the team shipped a user-facing release about once a month on average. Now, on a good week, we release several minor or mid-size features.
Is Scrum Serving You?
What I learned from this process is that “being agile” does not require following a framework by the book. What matters is whether your process works for you.
If your team is constantly interrupted, Scrum can turn into performance theater: lots of planning, lots of pressure, and repeated failure. In our case, dropping the sprint promise and switching to weekly priorities with continuous delivery helped the team focus on what mattered, pay down the debt that caused interruptions, and build momentum.
If you want a simple way to sanity-check your process, ask yourself:
What is the purpose of this meeting or ceremony—and is it actually achieving it? In our case, estimation was supposed to create predictability, but it consistently failed. The exercise became pointless.
What work keeps derailing us—and are we investing time to reduce it? Do you actively pay down technical debt, fix recurring sources of bugs, and automate repetitive internal requests?
Are we optimizing for flow of value, or for “hitting the process”? Do you ship continuously when things are ready, or wait for the sprint calendar?
Don’t be afraid to experiment. Try a small process change for the next two weeks. If it doesn’t work, roll it back and try something else. The change might feel stressful, but experimenting with the process in your organization is the only way to meaningfully improve it.
Somewhere along the way, the Agile Manifesto value “Individuals and interactions over processes and tools” got replaced by the Scrum Guide, certifications, and cargo-cult rituals. The moment a process stops fitting reality, it needs to be adjusted.
Scrum can be a great tool in some contexts. The real question is: is it serving your team—or is your team serving the process?
Is Scrum serving your team — or is your team serving the process?
If this resonated, subscribe, and you’ll immediately receive my free Process Experiment Template — a structured way to run your first process change this week.
Already subscribed? Share this with someone whose team is stuck in the sprint failure loop.
Have a nice week,
Roman