The Scrum Guide, the official definition of Scrum, has changed over the years. But various practices have become “standard Scrum” even if they’re no longer in the current guide.
In this article, I’m going to share 6 places where our recommendations differ from the official and/or standard version of Scrum. In some cases, we disagree with the current Scrum Guide. In others, the Scrum Guide has changed, usually to be less prescriptive, and we disagree with the standard thing people still do. Either way, here are our 6 favorite modifications to Scrum…
No Unlimited Backlog
Our #1 modification to Scrum is not treating the Product Backlog as an unlimited list. The default in Scrum is that anything can be added to the bottom of the Product Backlog, but only the Product Owner gets to decide to prioritize things higher.
In practice, this makes the backlog the place where everybody’s dreams go to die. But once something gets on the backlog, people start treating it as an implicit commitment. “When am I going to get my thing?”
This is bad for our brains because open commitments are stressful. And it’s bad for relationships because unkept promises, even implicit ones, erode trust.
Instead, only put things on the backlog that are likely to actually get done. Keep a separate list of ideas if you want, but don’t put unlikely items on the actual backlog. Use our PO Board backlog model to elaborate items as they move up the backlog so you don’t get too much detail too soon.
No Sprint Goal
We never recommend Sprint Goals. All the jobs a Sprint Goal can do (a big picture view, connection to purpose, alignment on the team) are done better by a hierarchical Product Backlog, where small items build up into larger items which work towards a purpose or vision.
Don’t bother with a Sprint Goal. Build purpose and context into your backlog. Then, the goal for the sprint becomes: do the most important work towards our larger goals.
Lightweight Sprint Planning
Sprint Planning, in our opinion, has one big purpose: Choose what to focus on in the upcoming Sprint (and, by implication, what not to focus on).
Much of what people do in Sprint Planning isn’t actually Sprint Planning. It’s Backlog Refinement that should have happened earlier. Or it’s detailed planning that should happen collaboratively during the sprint, whether in the Daily Scrum or just during the work.
Our advice? Do backlog refinement incrementally and continuously like we describe in our PO Board episode. Do detailed planning day-by-day in the Daily Scrum when you know more about the work. Focus your Sprint Planning meeting on answering, “Does this fit?” working from the top of your backlog. Once the answer is, “no,” wrap up Sprint Planning and do your first Daily Scrum to plan the first day of the Sprint.
(For more on effective Sprint Planning, check out our Sprint Planning episode.)
“Stories Talk” Daily Scrum
The Daily Scrum too often turns into a status reporting meeting about how busy everybody is on their own things. It should be the meeting where a team figures out how they’re going to collaborate to make progress on their shared commitment.
One root cause for the Daily Scrum as Status Report is the facilitation advice in the early Scrum Guide versions. They recommended going person-by-person, with each person sharing what they did yesterday, what they’re going to do today, and what impediments are in the way. This naturally leads to individual plans that may or may not intersect. (Add in tools that make it easier to work in parallel than to collaborate, and you get a team that not really a team—they’re a group that has meetings together and mostly works separately.)
Instead of going person-by-person, go story-by-story, and ask of the stories:
- What happened to get me closer to done yesterday?
- What’s keeping me from getting done?
- What’s going to happen to get me closer to done today?
Of course, the stories can’t talk. So, as the people speak for them, with a focus on the work instead of individual busyness, opportunities emerge to collaborate to move the most important work forward instead of just keeping busy separately.
(For more on this, check out our Daily Scrum episode.)
Bigger Than 9 Can Be Just Fine
The Scrum Guide recommends a team size from 5-9. And there are good reasons for this. Research shows that the best performing teams are just big enough to have the range of skills to get meaningful things done together but small enough for easy communication.
That said, we’ve seen plenty of occasions where a 9-person team isn’t sufficiently cross-functional to be able to complete increments of value without having to depend on other teams. In those cases, we’d rather see a larger team, at least in the short term, that breaks those outside dependencies. Everything just works better when work, especially complex work, is contained within the team.
We talked more about this here and here.
Don’t Cancel the Sprint, Add An Expedite lane
Finally, we differ with the Scrum Guide on what to do with interruptions and scope changes. The official advice is the protect the Sprint Backlog from changing, almost no matter what. And if it must change for some reason, cancel the sprint and replan.
We like the emphasis on focus. Too many people are scattered and constantly task switching.
But many teams need to balance new development with production support, and the official Scrum answer doesn’t help them. In that case, we recommend borrowing a couple of concepts from Kanban to balance focus and responsiveness. Check out our advice in this Humanizing Work Show episode (and subscribe to the show while you’re there!).
What have you seen?
I’m curious… What Scrum modifications have you tried that produced a good outcome for you? What are some you’ve seen that ended up making things worse? Share this article on social media with your thoughts and tag us!
Last updated