Why Sprints?

There was a time when sprints mattered, or more precisely, where you had to break work up into logical groupings. The reason was that a team needed visibility into hitting an eventual deadline for shipping a product. Maybe it was a quarterly release, where you could work back from the release date. Lots of planning, which rarely actually works, and then lots of shuffling and more planning when it doesn’t.

Sprints also served as a kind of finish line for developers to say “Yes, we got that block of work done.” There’s something really satisfying about setting objectives and then hitting them.

Nearly every development team I know uses sprints, and nearly every single one of them uses a two-week sprint. Why?

Sprints Are Unnecessary

In an environment where you’re releasing code every day, which is pretty common these days, what purpose does a sprint REALLY serve? With sprints comes sprint planning, where in my experience work expands to meet the sprint boundary. It also creates drag on the organization in the form of more meetings.

I’m not saying this is right for every organization, but if your product team is dragging, you might want to consider doing away with sprints entirely and just working from a well-defined product roadmap that’s much more real-time. When a piece of work gets done, developers pick the next item off the queue and get cranking on it.

Most importantly, you should never be doing something because that’s “how it’s done.” Question every assumption about your process, particularly when it’s not working for you, and don’t be scared to make changes or try new methods (or make up your own).

You can always go back to doing things the way everyone else does.