The two-week sprint is totally arbitrary. We adopt the convention without really questioning the wisdom, but by such dogma of what’s-good-for-the-gander bake someone else’s practice into our organizational infrastructure. The thinking is that two weeks is just about the right time to prototype, test, scrutinize, and deliver a feature. But, is it?

You can listen to this in your podcast app

All it took was David Grant raising that question as part of the Facebook Journalism Accelerator about this time last year for those of us at WhereBy.Us to concede the point and, within a week or two, consolidate to one-week sprints. Basecamp, just being Basecamp, shrugs the sprint convention all together, and just published a book that largely makes it clear we’re all just navel-gazing guppies trying to emulate other startups.

Shape Up, that book ☝️, made me question what practical reason do we actually need backlogs, or sprints, which was a refreshing reality check. I admit I find doing away with the backlog compelling - but that’s another writeup. Sprints, though?

This was originally written for my newsletter about high-level practical design thinking, Metric. Subscribe to show your support.

While reading about Basecamp’s six-week cycles, it dawned on me that the key feature of the sprint is its temporal midpoint. That is, given any deadline, your activity declines until you’re midway through a milestone before climbing. Why? You realize time is running out.

This is described by Daniel H. Pink as the “Uh-oh Effect” in When: The Scientific Secrets of Perfect Timing:

Human culture is organized around temporal milestones — the beginnings, middles, and ends of things — and so, subsequently, are our moods, hopes, productivity, and the like.

The sprint is an arbitrary division of time we tend to conflate with the timeline of a deliverable, but after about a year of one-week sprints I argue the deliverable is the least important aspect. Rather, the sprint is a structure for sustainably pacing our team’s movement through a service provision by placing temporal milestones at advantageous points.

• Beginning: the beginning of the sprint is a fresh start. It’s like New Year’s Day. We make good initial progress keeping our resolutions. We’re hopeful.

• Midpoint: the midpoint of the sprint is the ticking clock. It is, no lie, a stressor. It’s designed to make you go oh, shoot, and be honest with yourself and your squad about your progress.

• Ending: the ending of the sprint is the dropping of the curtain. Time’s up, we touch base, we fist bump, we move on.

Temporal milestones have different emotional tones and the midpoint tends to be the more anxious. Knowing this, however, allows you to design for those emotions, providing another project management tool for templating a mentally healthy sprint.

For instance, if the anxiety of the temporal midpoint is related to the build-up of to-do items you scramble get on top of, what if we just reduce the number of to-do items? Without reducing velocity, if you cut the sprint in half — from two weeks to one week — you move-up the temporal midpoint significantly, which not only reduces the number of to-do items that got away, but literally reduces the stress period between midpoint and temporal ending.

This is anecdotal but I’ll make a note to check the numbers, but I believe the temporal boon of the one-week sprint is a factor behind the increased “greenness” of the company’s team health. At a glance this feels counter intuitive, because surely one-week sprints equate to higher stress, but the reality is that in that same two-week period we have twice the emotional highs (beginning and ending milestones), and our milestone-related emotional lows are much briefer.

Liking (❤) this issue of Metric is a super way to brighten my day. It helps signal to the great algorithms in the sky that this writeup is worth a few minutes of your time.

Metric is a podcast, too, which includes audio versions of these writeups and other chats. Look for “Metric UX” in your favorite podcatcher.

Remember that the user experience is a metric.

Michael Schofield