Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

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:

Event
Timebox Duration
Sprint 30 days
Sprint Planning Meeting 8 hours or less
Daily Scrum 15 minutes or less
Sprint Review 4 hours or less
Sprint Retrospective 3 hours or less

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.

SUBSCRIBE TO THE BLOG


3 responses to “Why are there timeboxes in Scrum? Why operate in a series of Sprints?”

  1. […] “Why are there timeboxes in Scrum?  Why operate in a series of Sprints?” […]

  2. Carlos Geribón Avatar

    Hi! Timebox duration for Sprint retrospective was updated, now duraction is 4 hours for sprints one month.

  3. Ersan Avatar
    Ersan

    This is not correct. The latest (Nov 2017) revision of the Scrum Guide still states;

    “This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.