Why are there timeboxes in Scrum? Why operate in a series of Sprints?

If you’re “doing Scrum” and “being Agile”, what’s the purpose of these things called Sprints?  You might be thinking “Sure…timeboxes.  That’s why.  Scrum operates in a series a timeboxes.”  Right.  Scrum operates within a handful of timeboxes and assuming a 30 day sprint, then they are as follows:

But let’s dig a little bit deeper here.  There’s nothing magical about those time limits.  Surely we’re not all just going to these meetings and expecting to deliver amazing, done, and working software just because we obeyed the Scrum timebox, right?  What’s the purpose of these timeboxes?

Turns out that there are (at least) a handful of reasons.

A deadline.  Create a sense of urgency so that you focus on actually accomplishing something.

In a software development, sometimes there just aren’t meaningful dates.  If you know that you’ve got 6 months or so to get a piece of software delivered, there’s a very human tendency to let the work expand to fit the time.  Thinking about term papers that that I had to write in my high school and college classes, I knew that there were coming due for months and months but I didn’t really do a heck of a lot of work on them until about 1 week before they were due.  I basically wasted a ton of time and didn’t have much to show for it.  Now flipping that around, what would have happened if I had a deadline to produce some meaningful chunk of that paper every month?  I probably would have been a lot better about doing that work gradually across the term because I would have been doing small chunks of it over the course of that term.

Another example from software would be the problem of something called “earned value.”  Has anyone ever asked you how much you’ve gotten done on a feature and you said something like “I’m 82.1% done”?  Yah.  That percentage.  That’s earned value.  It’s bogus.  First off, where’d you get that 82.1% number from?  And secondly, how often have you seen a task go from 0% done to 80% done in the first moments of a project only to hang at 80% for the next 3 weeks.  That first 80% of the work takes 20% of the time and the remaining 20% of the work takes 80% of the time.  Dump that earned value stuff.  It’s done or it’s not done.  No more of these percentages.

Time to work.  Make sure that meetings don’t go on forever.

Another scourge of software development is meetings.  Non-stop, never-ending, relentless meetings.  In corporations, it’s very easy to call a meeting and very difficult to turn down an invitation to a meeting.  (BTW, check out this HBR article.)  And in lots of those meetings, do you really even get anything *done*?  Probably not.  The meeting had a weakly defined purpose to begin with and you all came together and pondered some silly thing and probably came to a weakly established decision that you’ll need to revisit later with yet another meeting.  In a typical day at work, you might go from meeting to meeting to meeting.  Hours upon hours spent discussing what you’re going to do when you eventually get down to work but precious little actual work.  (BTW #2, check out this other HBR article.)

Now Scrum doesn’t do away with meetings but they’re at least better defined.  And those timeboxes (the maximum duration for that meeting) help you to create a sense of urgency to actually produce something.  You don’t just have a meeting that goes on for 4 hours, you’ve got a meeting that goes for 4 hours (or less!) and there’s a required output from that meeting.  There’s a purpose.  You get that stuff done, you exit the meeting, and then you get down to actually doing work.  And in those times when you’re *not* in a meeting, you should be largely undisturbed so that you have time to get into a state of flow and actually get some work done.

Inspect + Transparency.  Force you to pause and take stock of what you’ve done.

Thinking about that Sprint — what’s the goal?  The goal is done, working software (aka. the Increment).  So at the start of the Sprint, you’ll have a Sprint Planning meeting where you come up with a forecast for what you’re going to achieve in that Sprint.  Then you go do your work and at the end of the sprint, you’ll have a Sprint Review Meeting followed by a Sprint Retrospective Meeting.  In that Sprint Review, you’ll show off your done, working software and *only* your done,  working software.  If it’s not *done* you won’t show it.  Put another way, you *WILL NOT* demonstrate any partially working or partially implemented software features.

So, if you’re on a team and your team doesn’t have much or anything Done to demonstrate at the Sprint Review, do you think you or anyone else will notice?  Heck yes! They’ll notice!

What’s going on at the end of that sprint?  You’re taking a pause as a team.  You’re saying, “alright, we forecast that we’d get X, Y, and Z features done in this sprint and we only got Feature X done.  Feature Y and Feature Z is not done.”  That’s some hard data.  One feature is done and two features are not.  There’s no fuzziness here.  There’s no “well, I was busy” or “it was hard” — it’s just answering the question of is something done or not done.  You might have been busy and it might have been hard but the unavoidable truth is that there’s only one done feature.  There’s no delusions.  You can’t trick yourself into thinking you’re close.  It’s done or not and it’s transparent.

After that Sprint Review, you’ll have a Sprint Retrospective meeting where you’ll have the opportunity as a team to discuss how you did in the sprint and how your delivery process is.  Here’s where you discuss the “I was busy” or “it was hard” kind of stuff.  You’ll take a look at what went well, what didn’t go so well, and what you’ll try to improve for the next sprint.

At this point, you might be thinking “well, that’s just swell.  The team comes together and cuddles and sings songs and we all feel great.  That sounds stupid.  What does this have to do with delivering software?”   Well, the benefit of coming to a complete stop and looking at how you did and how you did what you did is this — if you were stinking at doing something and it was hard and you were making mistakes, you notice that you did this AND THEN STOP DOING IT!  That firm end to the sprint timebox gives you clear moment to improve your process and limit your risk.  Your risk should be at MOST the length of the sprint and every 30 days, you’ll stop doing any dumb and unproductive things that you’ve been doing and get better at producing and delivering that software!

Summary

Scrum isn’t just about having meetings and about having someone watching the clock while you do your work.  It’s about inspecting what you’re doing so you can adapt and improve.  It’s about making sure that you’re actually delivering done, working software.

-Ben

— Looking for help getting to done, working software?  Want to learn more about Scrum or train your team on Scrum?  Need a tune-up for your existing Scrum process?  We can help.  Drop us a line at info@benday.com.