Understanding Sprints and Timeboxes

There was a lot of buzz and critics about Scrum-like Sprints around the last time. One of the merits of the discussions was that now only the how but also the why was discussed. I try to do a short wrap up of what I read and think.

Forcing Hard Decisions

A Sprint in Scrum is timeboxed. Every Sprint has the same length and it ends when the time has come – no matter how much we completed. Jim Highsmith wrote on Twitter about timeboxes: „I’ve always said timeboxes weren’t about time, but about forcing hard decisions.“ I think this is an important statement since it questions what a lot of Scrum teams do: Plan what to do during the Sprint and get the approval for that in the Sprint Review. When we look at the Sprint through Jims Eyes we get something different. First we have to think about the „hard decisions“ we want to force. There are definitely several options. In my point of view there are two very important questions nowadays, that are related to each other:

1. Did we validate or invalidate our assumptions?
2. Did we produce value for customers and users?

The Sprint timebox forces us to decide how to proceed based on the feedback we got. Should we pivot or persevere? Should we stay with the current Product Backlog or adapt it?

Without timeboxes it is – of course – still possible to force these hard decisions. But most of us like to avoid hard decisions and tend to postpone and postpone and …

Creating Rythm and Flow

Tobias Mayer wrote on Twitter: „Reading anti-timebox tweets. It’s amusing how much disgust is aimed at a unit of time. Units of time create rhythm. Rhythm creates flow.“ He added a blog post called „Timebox != Commitment“ where he explains his perspective on timeboxes. It is NOT:

1. Set a timebox size
2. Commit to a bunch of work
3. Realize you are failing to complete it all
4. Rush to finish
5. Produce crappy work
6. Be exhausted
7. Go to #2—repeat until dead, or company goes out of business

But it is:

1. Set a timebox size
2. Engage in dialog with requester/s. Review requests, prioritize
3. Select a request, small enough to fit inside the timebox
4. Complete the work to the satisfaction of the requester
5. Breathe [reassess remaining requests if necessary]
6. Go to #3—until there is no request that can fit in the remaining time.
7. Stop work [if time remaining, take Slack time]
8. Reflect. Learn from mistakes, and adapt accordingly
9. Go to #2—repeat until all requests met, or deadline arrived at.

This perspective is supported by the latest modifications to the Scrum-Guide published by Ken Schwaber and Jeff Sutherland: The development does not commit to the Sprint Backlog but does a forecast (like a weather forecast) about what might be achieved.

Other options

Scrum-like Sprints are one possible implementation of timeboxes. I know of at least two other possible implementations. Here are the three options I am aware of:

1. In Scrum we batch together a set of features during the Sprint Planning and use this feature set for the Sprint Review.
2. In Kanban planning and release/review cadences are often decoupled. Review cadences can still be used in a timeboxed way (in the sense of Jim Highsmith to force hard decisions). In this case we batch together some features for review but not for planning.
3. Eric Ries suggests to have a kind of deadline per feature in his book „The Lean Startup„.

In the end it is just the question of when and what to batch together and that is a question of transaction/coordination costs. Batching features together for a review is an easy-to-implement solution when we want to get face-2-face feedback from customers and users. When we have a lot of active users and work a lot with Lean Startup-like cohort metrics and the like we may not need to batch together features for review. Batching features together for planning is an easy solution when the „feature requesters“ are not continuously available. When the „feature requester“ is available all the time (e.g. because the Product Owner role is shared across the team) it may not be the best solution.