Let’s talk about sprints. What’s the right length? When should they begin and end? On a Monday and Friday, respectively, or is another schedule more appropriate? Should we ever change the length of our sprints? These are all good questions, and we’ll get to them, but let’s start with something more fundamental. Why even have them?
In interviews, I’ll often ask this question to Scrum Masters:
What part of the Scrum framework do you find odd or disagreeable?
My answer? Sprints. I find them odd. How often do we scoff at deadlines? Deadlines are for waterfall projects, not for the awesome product that our Scrum team is crafting, we say. Then we point to the iron triangle, talk about how we prioritize our backlog guaranteeing the most important work gets done first, and finally we negotiate scope to meet whatever dates are necessary. But don’t tell me that this story needs to be done by September 1st. That’s not how we operate.
But isn’t the end of a sprint a deadline? There’s nothing special about the date. Nothing terrible or earth shattering will occur if all the work isn’t completed by then. Douglas Adam comes to mind:
I love deadlines. I like the whooshing sound they make as they fly by.
Don’t misunderstand me. I agree with the construct of a sprint, and I think it reinforces a mindset toward iterative and incremental development. Further, I’m not suggesting we toss out sprints, and I’m not suggesting we don’t take our sprint commitment (or forecast) seriously. Quite the contrary. Some might also point out what I write today conflicts with my previous blog post about The Importance of Sprint Commitment, but I don’t think so. I simply find it odd that, in one breath, we scoff at deadlines, but, in the next breath, we insist the team get everything done before the sprint ends.
So be careful when emphasizing the end of the sprint and undone work. Learn when to lean on the team and when to silently observe. Why?
The goal of the Scrum Master is to create a learning team, not a faster team.
Sure. The result will likely be a faster team, but it should never be our goal. In our next blog post, we’ll tackle some of the questions that started this post. We’ll discuss sprint length, cadence, and whatever other questions are asked in the comments below so stay tuned.
One final thought as we close. I realize now that my point is much bigger than sprints as deadlines:
- Just because it’s part of the Scrum framework doesn’t make it scripture.
- Just because it’s not part of the framework doesn’t make it wrong.
- Just because we’re zealots doesn’t mean everyone else is.
Keep this in mind as we work with our teams.
Do you want to get notified when new posts are published? Leave your email below.
This is why it needs to be explicitly understood that the scope of a sprint is flexible. The fact that sprints are short make the impact of flexible scope on a sprint much less troublesome, but we have to allow for it.
This is why I advocate the thinnest possible stories, small WIP, and allowing the PO to substitute any new story for comparable stories that were scheduled and have not yet been started.
This means also getting rid of the archaic nonsense about Sprint Goals and blowing up sprints if the Sprint Goal has been destroyed by business demands. I have yet to see any team have meaningful, distinctive Sprint Goals for more than 2 or 3 consecutive sprints. These always devolve into something like continuing last sprint’s goal or doing the stories that the PO wants done.
I’ve had a love/hate relationship with sprint goals myself. In theory, I can see the value. In practice, not as much. They can be useful to summarize what you’re up to in a sprint, but can’t viewing the backlog do just the same? They could be useful in getting the team out of the weed for a moment to help them realize the outcome we hope to shape, but does it really do that? What do you do if we notice that the sprint goal(s) are only about a fraction of the sprint backlog? Are your goals wrong, is it too noisy, is there a bunch of tech debt that was important to pay off, or does it even matter? IME I haven’t seen a lot of value to the goals, but since the cost is low, I’ve not devoted much time into doing much about it.
I did a little experiment where I held a very minor %5 of each team member salary and held it against percentage of undone story points. The trick is the he while team got the deduction, not an individual.
The amount was less than the cost of a pack of cans but everyone started to focus more not on their own work but really attentively listen in stand up meetings and help push any blockage that had the slightest chance of not having a 100% closure on the sprint stories.
They also were laser focused the next standup to truly understand every thing about the upcoming sprint. Really detailing things upfront.
I only deducted one sprint and the rest were perfect.
Correction “The trick is the whole team got the deduction, not an individual. It was the team responsibility now.”
Thanks for sharing. What do you think the team learned from that experiment?
The problem with holding teams to story points planned is that it creates at least as much estimation pressure as development pressure.
When you create estimation pressure, it creates more wasted time trying to estimate better, which leads to waterfallish specification and heavy planning.
The idea is counterproductive in the long run, which is exactly why the term commitment has been replaced with forecast.
That’s the best argument I’ve heard to date for forecast over commitment.