Everything that happens in Scrum happens within a ‘timebox’. There’s the 30 day (or less) overall Sprint and then there are timeboxes for the events within a Sprint. There’s 8 hours (or less) for the Sprint Planning Meeting. The Daily Scrum gets 15 minutes. Then 4 hours (or less) for the Sprint Review followed by 3 hours (or less) for the Sprint Retrospective.
With all these timeboxes it’s easy to start thinking that Scrum is a race. “HURRY UP! GO! WE’RE UP AGAINST THE CLOCK! WE’VE GOT TO FINISH!”
Take a breath. Take a moment. Take another breath. Observe your own thoughts and let them go. Focus. Try establish a sense of inner calm. Try to find some peace.
Scrum isn’t a race.
“We failed our Sprint.”
So many teams that I work with say things like “we failed our Sprint” or “we weren’t successful in our last Sprint”. They’re legitimately concerned by this – not so much because they didn’t deliver their software – but because they didn’t deliver what they originally “committed” to do. They’ll often say “we missed our commitments for this Sprint.” It’s understandable that they’re disappointed but it’s subtly missing the point.
The point of the Sprint isn’t about getting the work done. The point of the sprint (more precisely the end of the Sprint) is about noticing whether or not you finished the work. The leftie, sandal-wearing, hippie version is that the end of the Sprint is about mindfulness. The less touchy-feely way to say it is that the end of the Sprint is about capturing the data about what was done and what wasn’t done.
Data-driven Mindfulness
Think back to when you were in science class. Remember when you had to do those labs and experiments? And then there were also those lab reports where you filled out with the details of what you did during your experiments. What was the first thing you were supposed to do? You were supposed to come up with a hypothesis. What was the last thing you were supposed to do? You were supposed to confirm (or disprove) your hypothesis.
Now what does a high school lab report have to do with Scrum? Well, you’re basically doing something that’s very similar to the Sprint Planning Meeting (SPM) and the Sprint Review. In the SPM the team comes up with the forecast of what they think they can do in this sprint and in the Review they check to see whether or not they managed to actually do it.
In science, it’s a stone-cold bummer when your hypothesis is proven wrong but it’s not really a failure. It’s just data. Same think in Scrum. That Sprint Review Meeting (where you show off your done, working software) is where you stop developing software, walk away from your desks, and look at whether or not you managed to deliver on your original hypothesis. “We thought we were going to get X, Y, and Z done in this Sprint. Did we? If yes, great. If not, why not? If not, what did we actually get done?”
The Heisenberg Uncertainty Principle of Scrum
Heisenberg's uncertainty principle of quantum mechanics states that you can know where a particle is or how fast it’s going – but you can’t know both of those at the same time. I’m mentioning this 1) to show off what a smarty-pants-science-nerd I can be and 2) to stress how important it is to come to a complete stop at the end of each Sprint.
Some teams – especially when they’ve figured out that their Sprint is “in trouble” – skip the Sprint Review Meeting. “We don’t have anything done so why bother?” or “We just have to be ‘heads-down’ right now so we can get it done as soon as possible.”
[error buzzer] Wrong answer!
Come to a complete stop and do your Sprint Review. It doesn’t matter how you think things are going. Stop. Take a breath. Notice where you are and what you actually have done.
You can only know where you are if you stop moving. You only really know how much you got done if you stop and look at what you got done. Otherwise, you’ve only got a sense for whether you’re going fast or slow but you’ll never really actually know where you’re at or what you got done.
Predicting the Future
Whatever you managed to get done in that Sprint is your Velocity. You’ll use that Velocity data to create forecasts to help you plan for the next Sprint and for forecasting the future of your project.
Whether or not you got all of that work done in the Sprint isn’t especially relevant. Personally, I don’t particularly care if you finished or not. It is what it is. If I’m your Product Owner or manager or a stakeholder, getting angry doesn’t help at all. Asserting (often loudly) that “I want it by [insert date here]!” doesn’t help either.
You’re capturing that velocity data so that you’re planning with actual data rather than hope. Knowing what the team actually managed to make happen (or not happen) in that period of time (the Sprint’s timebox) helps me a lot because now I can make better plans for the future. I can make plans that are based on 1) knowing the current state of the product and 2) knowing how much the team has managed to accomplish in the past. Now, past performance does not guarantee future results but it’s a lot better than just guessing and it’s more clear-headed than asserting “I want it by [insert date here].”
The Perfect is the Enemy of the Good
As Voltaire wrote in La Bégueule, “The perfect is the enemy of the good.” Ok. So I have to admit – until 2 minutes ago, I had absolutely no idea that that quote was by Voltaire. But it’s a good one and it’s relevant to Scrum’s timeboxes.
The Sprint timebox is about non-judgmental, data-driven mindfulness. Did you get it done or not? And what’s your Velocity? I’m going to assume that you tried your best and, for right now, I only want the data. So that’s mindset of the overall Sprint timebox. But when it comes to the timeboxes within the sprint – the sprint planning meeting, the daily scrum, the sprint review, and the sprint retrospective – the purpose of the timebox is a little different. Actually, the purpose of those meetings is a little different. While you use the whole sprint in order to generate an output, in these other timeboxed meetings, you’re expected to produce an output in that specific meeting.
And whooooaaaaa Nellie! Does that ever get teams tripping over their feet. Teams get stuck trying to create the metaphysically perfect output of each of those meetings. They get so locked in on trying to make some perfect output that they waste a ton of time and end up with practically nothing.
It’s important to remember 1) what the goal of each of those meetings actually is and 2) that you aren’t perfect. Scrum is about continuous improvement and practicing until you achieve mastery. Don’t beat yourself up if you don’t get stuff 100% perfect but do try to notice how well you did and try to improve.
Here’s a quick cheat sheet for the goals of each of those meetings.
Sprint Planning Meeting: 1) figure out what you’re going to do in the sprint and 2) figure out how you’re going to do it.
Daily Scrum: As a team, how are we doing? How are we progressing towards delivering the done, working software at the end of the sprint? Is the plan from the Sprint Planning Meeting still relevant? Does it need any changes? Is anything blocking us from getting it done?
Sprint Review: Inspect where you’re at and gather feedback on what got done. And while you’re at it, gather feedback on where you’re planning to go, too.
Sprint Retrospective: How did we do in this Sprint? What went well? What didn’t go so well? What should we attempt to improve in the next Sprint?
Summary
If I can give one piece of advice, it’s to stop worrying so freakin’ much. Specifically, stop worrying so much about success and failure. Worrying doesn’t make anything go any faster. If I can give another piece of advice, don’t forget to measure what you got done and use that data to plan for the future.
In short, chill out, slow down, and look around.
-Ben
-- Are your teams a little too frantic? Is it all heat and no light done, working software? We can help. Drop us a line at info@benday.com.
Related article:
“Why are there timeboxes in Scrum? Why operate in a series of Sprints?”
