A few years into writing software professionally, I sat in a sprint planning meeting where we spent forty-five minutes arguing whether a ticket was a 3 or a 5. Forty-five minutes. The actual work took an afternoon. That meeting was longer than the task.
That’s when it clicked for me: nobody in that room actually cared about the number. We were performing a ritual we half-understood, hoping the ritual would produce the outcome the books promised. It mostly didn’t. So here’s what I’ve picked up about Scrum from the engineer’s seat - the stuff the Certified Scrum Master slides skip right over.
standups are for unblocking, not status theater
The daily standup is the ceremony that goes wrong fastest, and it goes wrong the same way every time. It turns into status reporting to the manager.
You know the version. Everyone lines up, recites “yesterday I did X, today I’ll do Y, no blockers,” and nobody listens to anyone else because they’re rehearsing their own bit. It’s a progress bar rendered in human voices. Pointless.
The whole point of a standup is to surface the thing that’s stuck so someone can unstick it. That’s it. If I say “I’m blocked because I can’t get the staging DB to seed,” the correct outcome is that whoever knows the seed script grabs me after. Not “okay, noted, next person.”
The best-run standup I was ever part of had a rule: if your update doesn’t mention a blocker or something another person needs to know, just say “on track” and pass. Updates went from two minutes to ten seconds. The whole thing took four minutes. Everything else - the actual “what did you do” - lives in the tickets and the PRs where it belongs.
If your standup is a place where people prove they were busy, kill it or fix it. It’s not helping you ship.
estimates are guesses wearing a suit
Story points are the thing everyone fights about and almost nobody uses well.
Here’s my honest take after estimating hundreds of tickets: the number is a guess. A structured, slightly-informed guess, but a guess. The Fibonacci scale (1, 2, 3, 5, 8, 13…) isn’t magic - it exists purely because the gaps get wider so you stop pretending you can tell a 6 from a 7. You can’t. Nobody can.
What points are actually good for is flagging uncertainty. When I estimate something an 8 or 13, I’m not saying “this is thirteen units of work.” I’m saying I don’t understand this well enough yet and we should talk before I start. A 13 is a smell, not a size.
The trap is treating velocity as a productivity metric. The second a manager says “last sprint you did 40 points, this sprint only 32, what happened,” the whole system rots. Everyone inflates their estimates. A 3 becomes a 5. Velocity climbs, nothing ships faster, and now your points are worthless as a planning tool because they’re a performance score.
If I could change one thing about how teams estimate, it’d be this: estimate to decide how to split the work, then stop caring about the number. A task like this:
[ ] Add user notificationsis a lie disguised as a ticket. What kind of notifications? Email? In-app? Both? Do we need a preferences screen? That’s not an 8, that’s five tickets pretending to be one. The estimate’s real job is to force that conversation. Once you’ve split it into:
[ ] Notification data model + migration
[ ] Send email on new comment (behind a flag)
[ ] In-app notification bell + unread count
[ ] Per-user notification preferences pagethe points barely matter anymore. You’ve already won.
”definition of done” is where the silent bugs hide
This one bit me hard, more than once.
Early on, “done” meant “the code works on my machine and I opened a PR.” Then I’d merge and something would break in a way that was technically not my fault but very much my problem. No tests. No error handling for the empty state. Worked great until someone had zero items in their to-do list and the whole page threw.
A real definition of done is a checklist you agree on before the sprint, and it’s boring on purpose:
Done means:
- Tests written and passing
- Error + empty states handled
- Reviewed and approved by one other person
- Merged to main, deployed to staging
- No new linter warningsThe value isn’t the list. It’s that “done” stops being an opinion. Without it, every engineer has a private definition, and the gaps between those definitions are exactly where bugs slip into production. I’ve watched a feature get called “done” three separate times - done by the dev, then “actually not done” in QA, then “actually not done” again after release - purely because nobody wrote down what the word meant.
Write it down. Stick it somewhere annoying. It saves you the “wait, I thought that was finished” conversation, which is the most demoralizing conversation in software.
scope creep doesn’t announce itself
Sprints are supposed to be a fixed box of work you commit to and protect. In practice, the box leaks.
It’s rarely dramatic. Nobody bursts in demanding you rebuild everything. It’s the small stuff. “While you’re in that file, can you also…” Sure. “Oh and it’d be great if the button was blue.” Fine. Ten of those and suddenly you’re behind on the actual committed work and you can’t point to a single villain, because every individual ask was reasonable.
The move that helped me most: write the extra thing down as a new ticket and let someone else decide if it jumps the queue. Not me, mid-sprint, being nice. That reframes it from “quick favor” to “new work that costs something,” which is what it actually is. Half the time the answer is “oh, next sprint’s fine” - it was never urgent, someone just said it out loud while I happened to be listening.
retros are the one meeting worth protecting
If I had to cut every Scrum ceremony but one, I’d keep the retrospective. Easily.
Standups can become status theater. Planning can become the points argument. But the retro is the only regular slot where the team stops shipping and asks “what’s actually broken about how we work.” Not the code. The work itself. That’s rare and it’s valuable, and it’s the first thing that gets cancelled when a deadline looms - which is exactly backwards, because that’s when you need it most.
The retros that worked weren’t the ones with sticky notes and “start/stop/continue” columns. They were the ones where somebody said the real thing out loud. “The reviews sit for two days and it’s killing our momentum.” “Planning runs long because the tickets aren’t refined.” Concrete, a little uncomfortable, with a named owner and one change to try next sprint.
A retro that produces zero changes is just a group therapy session where everyone agrees things are bad and then does nothing. One real fix per retro. That’s the bar. Anything more, and you won’t follow through anyway.
that’s basically it
Scrum isn’t the point. Shipping working software without hating your job is the point. The ceremonies are tools, and like any tool you can hold them wrong.
Standups to unblock. Estimates to split work and spot fog, not to grade people. A written definition of done so “finished” isn’t a vibe. Guard the sprint from the friendly little leaks. And whatever you cut when things get busy, keep the retro.
Do that and the framework mostly disappears into the background, which is honestly the sign it’s working. When you’re arguing about whether it’s a 3 or a 5 for forty-five minutes, it very much is not.