Over the past few years, I worked with over half a dozen teams claiming to be agile and implement some version of scrum.
Even though on paper they were all doing some form of scrum, in practice, my experience varied wildly from one team to another. It’s almost as if the term has become meaningless.
This isn’t a rant against scrum and agile but rather a semi-structured, subjective review of what I think works well and what doesn’t.
Sprint
A sprint should be as long or as short as needed. Two weeks is a good rule of thumb for most teams, but adjust the sprint length as your team gains experience.
Think of the sprint as a contract among team members; don’t add or remove things lightly.
Daily Standup
1- It doesn’t have to be daily.
2- It doesn’t have to be in the morning (good luck with distributed teams).
3- It doesn’t have to be synchronous.
The most common mistake is when the daily standup becomes a time for the team to read aloud what’s already in the ticketing system (Jira, Asana, Monday…). Those tools exist so anyone on the team can check the status of tickets anytime.
The standup should be a time to highlight new risks, uncertainties, dependencies, or anything unexpected that’s hard to capture in a ticket. As the team mindlessly reads through Jira cards one by one, no one brings up that they are blocked by another team.
Some folks feel the need to prove they worked on something yesterday, while others just enjoy talking. Keep this ritual short, actionable, and unobtrusive.
Tickets / Tasks / Epics / Initiatives
Write tickets—not too many, mostly self-contained tasks.
There’s pressure on product managers to accurately reflect what their team is working on, often leading to an avalanche of tickets, subtasks, and micro-tasks. But at some point, managing tickets becomes a job in itself—congrats, you’ve just invented bureaucracy!
The product manager breaks down every UI tweak into a micro-task, and soon the backlog becomes harder to manage than the codebase itself.
What about urgent bugs or incidents?
In theory, your team is working at capacity during a sprint. To handle unexpected issues, you have two options:
- For every unexpected emergency taken on, remove an “equivalent” low-priority planned task.
- Bake a buffer into your sprints for unexpected work. If there are no emergencies, dedicate this buffer to tech debt or skill development.
Story Points and Estimations
Fugayzi, fugazi. It’s a whazy. It’s a woozie. It’s fairy dust. It doesn’t exist. It’s never landed. It is no matter. It’s not on the elemental chart. It’s not real.
Time or complexity?
Too much time has been wasted estimating with story points and complexity instead of just accepting the obvious. Every developer I’ve ever worked with did the mental math to translate story points back into days, and vice versa. This is a charade.
You don’t even need points. In most cases, t-shirt sizing is more than enough. Here’s a rule of thumb I use:
- XS - 1 hour
- S - 1/2 day
- M - 1 day
- L - 3 days
- XL - 1 week
- XXL - 2 weeks
Planning Poker
For most teams, this is a waste of time: a backend developer has no business telling a frontend that a form is 5 points instead of 13.
The only context where planning poker could be useful is when you have a homogenous team with comparable skills working on the same stack.
Most teams I’ve worked with already know who will take a given task, even before estimating it.
Retrospective
A retrospective is where you can review what went well, what didn’t, and how to improve.
Most teams forget that this includes reviewing their processes as well! Don’t be afraid to challenge your team’s process during these sessions.
I don’t like the glad / mad / sad template often used in retrospectives. Templates shape the answers and suggestions you’ll get, so find something that resonates better with your team.
Agile and scrum succeed when they are adaptable, not dogmatic. Use these practices to improve clarity, focus, and adaptability for your team—not as strict rituals. Be very wary of anyone who wants to sell you a one-size fit all package.