I've been on scrum teams for about nine years now, with varying degrees of rigor. In that time I've watched it go from a newfangled methodology to the de facto way projects get managed (or mismanaged). The list below is what I've learned along the way. As most lists go, it's somewhat idiosyncratic. YMMV.
Scrum is not suited for all types of projects
Lest this sound like heresy, let me clarify. Scrum expects that the team is left relatively undisturbed to work on tasks picked up during a sprint. If a team's work is largely reactive (and this is the case for teams handling a fair number of customer issues), there are methodologies that fit better, like Kanban.
Customer issues are also notoriously hard to estimate. Triage, reproduction, fix, verification: traditional scrum estimation techniques (t-shirt sizing, planning poker) often fall apart here.
Inspect and adapt instead of blindly following the rules
I've lost count of how many times I've heard the complaint about "not doing scrum right" when the team is faced with changing business priorities mid-sprint. If your scrum master starts quoting rules by chapter and verse, you may be doing it wrong.
Think about the spirit of the law, not the letter. The agile manifesto is worth rereading:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
You refactor code all the time. You should not be afraid to refactor your process based on what does or doesn't work for your situation.
Some questions worth asking in retrospectives: Does your process make you wait until the end of a sprint to push to production? Since tasks are worked on in priority order, is it OK for high-priority items completed early to sit waiting for lower-priority items? For a SaaS product delivering value continuously, how does a rigid two-week sprint cycle actually help?
On unexpected high-priority customer issues: do you invoke "abnormal sprint termination" as a weapon, or tell the customer to wait until the next planning meeting? Teams can handle this pragmatically. Adding a ticket mid-sprint is fine occasionally, as long as you drop something of equal weight. Let the product owner make that call; it also forces an honest assessment of the interruption's actual priority.
Make standups matter
A peer manager once disparaged the standup as ten minutes of people going around saying "I ate yesterday, I will eat today, nothing is blocking me from eating." (He didn't use the word "eat," but you get the idea.)
What a standup is not good for:
- Status updates. Status belongs in tickets.
- Raising blockers. Don't wait until tomorrow to surface something blocking you today. That's a wasted day.
What it is good for: refocusing the team on what matters, and passing the baton between team members. Five minutes or less. First thing in the morning, before anyone context-switches into deep work. Ideally the only recurring meeting the team attends in a day.
Use the right metrics
Scrum tooling tends to push teams toward velocity as the headline metric: tickets closed per sprint. That's a vanity metric. The right measure is customer value delivered.
Done means shipped
Scrum teams often congratulate themselves in review meetings on the number of tickets "accepted" by the product owner. Code that passed review and tests feels done. But for a customer, it means nothing until it's in their hands.
Done means the code is shipped. For a SaaS product that means migration scripts, release notes, runbook updates, and supporting the path through staging to production. Keeping a ticket open through those stages forces you to track the metric that actually matters: customer value delivered.
Watch the big picture
The rapid develop-demo-feedback loop works well for execution and allows quick course correction. But it is also one of the sources of trouble on agile projects.
Scrum focuses on small steps and bite-sized chunks of functionality. That's a good idea, but only if the overarching architecture and roadmap have been defined up front. Without that, small steps can walk the team off a cliff: delivering product that is hard to support, extend, or scale.
A good technical leader needs to hold the big picture in their head, articulate it clearly to the team, and make sure it guides day-to-day decisions.
Broken windows
Backlog prioritization means the team only works on high-value issues. Small, low-priority problems (an inconsistent form field label, misaligned UI elements, a confusing error message) never get picked up in a backlog of sufficient depth.
That's not a problem by itself. But a collection of these things, over time, is exactly the broken windows effect: individually minor, collectively the thing that makes a product feel shoddy and unmaintained.
A good product manager keeps these from falling through the cracks permanently: rolling them into a higher-priority usability story, using them as onboarding exercises for new engineers, or carving out a cleanup sprint now and then.