It always starts the same way.
The ticket comes up in sprint planning. Someone says “it’s quick, two days max”. Everyone nods. Nobody asks questions. The ticket enters the sprint with a 3-point estimate and a collective energy of “we’ll knock this out fast”.
Three weeks later, the ticket is still there.
“Quick win” is the best promise in product development. And the most dishonest one.
Not out of bad faith. Out of optimism. Out of wanting to do well. Out of that little voice saying that this time it’ll be simple, the code is clean in that area, nobody has touched that module in a while so it must be stable.
Spoiler : the code is never clean in that area. Someone always touched that module. And “nobody’s been in there for a while” is exactly why it’s going to take time.
Estimation isn’t prediction. It’s storytelling.
When a developer says “two days”, they’re telling a story. The story of an ideal world where specs are clear, dependencies are known, tests are written and the rest of the sprint is empty.
That world doesn’t exist.
The real problem is that everyone knows it. The dev who estimates. The PO who approves. The Scrum Master who writes it down. And yet nobody says anything. Because challenging an estimate in sprint planning is socially uncomfortable. It slows the meeting down. It feels like blocking the team.
So we write 3 points and see what happens.
We see what happens. Three sprints later.
Here’s what actually happens on a “quick win” that goes sideways. First sprint : the task starts, we discover an undocumented dependency. We block. We defer. Second sprint : back to it, but a critical bug elsewhere pulls the devs away. The ticket waits. Third sprint : we finish, but tests reveal a side effect. Fix, re-test, late merge.
Nine weeks for a two-day estimate. Velocity takes a hit. And nobody quite understands why the sprint wasn’t delivered.
Technical debt is the interest on every badly estimated quick win.
Every shortcut taken to ship fast becomes a constraint for the next ticket. And the one after. Until every “quick win” automatically becomes an investigation, because the code is so loaded with undocumented history that no change can ever really be quick.
That’s technical debt. Not an abstract concept from a tech conference. Tickets estimated at 3 points that land at 13.
What if we removed “quick win” from our backlogs?
Not because the intention is bad. Because the word creates an expectation that poisons the estimate before the conversation even starts.
A spike to investigate before estimating. Collective honesty about what we don’t know yet. And the acceptance that wanting something to be fast doesn’t make it fast.
Your next sprint planning deserves that conversation.
So, do you ban it or keep it?