V. We Will Not Sprint

Sprints used to be controversial. Now they are commonplace in engineering organizations—so much so that it’s controversial to say that sprints are a bad idea.

Sprints are a bad idea.

I suppose if you had to decide between using two-week sprints or an annual release cadence, sprints are the winner. But that’s not what you are deciding between.

In a nutshell, sprints are (usually) a two-week block of time to undertake a number of features, fixes, and other dev work. The work is planned before the sprint begins, and the results are evaluated afterward.

In theory, this fixed block of time forces the team to break work down into smaller, shippable parts. Any project or task that is too large to be completed within that time gets split up. Having short-term deadlines for shipping adds some urgency to overcome decision paralysis and mitigate scope creep. Likewise, any work that isn’t a priority will be pushed into the future, when it won’t be crowded out by higher-priority tasks. Additionally, having work planned out and visible for stakeholders and other interested parties is a bonus for transparency, and holding retrospective meetings to complete the learning feedback loop is great.

Those are all nice things. We can and should have all of them. However, sticking to an arbitrary two-week schedule is not necessary. I’m sure it was helpful in the past, but in today’s world, it causes more harm than good.

A good metaphor for a sprint is a backpack. The backpack has a fixed size. You can fit a lot of small items in there, or you can fit a few large items. You can also do a mix. If someone wants you to carry a piano for them, it’s easy for you to say, “Sorry, my backpack doesn’t have room for that. Is there a particular part of the piano that would be helpful for me to carry?”

Of course, backpacks can also be frustrating depending on the size and shape of the objects. It’s rare that you’ll have the exact combination of items that will completely fill the backpack without going over. Often you’ll have a bunch of space left over, or worse, it’ll be packed so tightly it breaks open during your travels and dumps your possessions all over the ground.

It’s dumb to play this guessing game every other week. If you don’t plan enough work for the sprint, devs will either be idle or break the spirit of the sprint by taking on future work. If you plan too much work, your devs will miss the deadline. There isn’t even any benefit to guessing correctly. Stakeholders only care about estimates for their particular features, not the sprint as a whole.

Does it make sense to use the size of your backpack as an excuse for not being able to carry someone’s piano? No. You don’t need a two-week sprint to avoid taking on large projects that haven’t been broken down into shippable pieces. Just make a rule that you don’t take on large projects that haven’t been broken down into shippable pieces.

Similarly, if you were relying on the fixed size of sprints to push non-priority work into the future, you can still do that. If someone wants you to work on something immediately, just show them your current list of projects and ask which one they want to replace.

If you want to have a retrospective, status, or planning meeting every other week, fantastic. Any project that has been planned or shipped since the last meeting is a great topic for discussion, but artificially constraining projects to this arbitrary cadence is unnecessary.

Here’s the thing: You can break work down into small, manageable parts. You can push unimportant, non-urgent tasks into the future. You can be transparent about what your team is working on and why. You can regularly sync up for a feedback loop on what’s working and what isn’t. I recommend doing all of these things. However, none require you to shoehorn all your projects into two-week periods.