The concept of ‘sprints’ is one of the truly ubiquitous components of agile development. Other elements of agile workflows are often abandoned or ignored. There are teams that don’t do planning meetings. There are teams that don’t do retrospectives. Many teams don’t work directly with customers. Many elements of the agile manifesto can be ignored (https://agilemanifesto.org/principles.html), but the two week sprint is one of the most enduring.

But the two week sprint isn’t even in the manifesto. And most teams probably don’t benefit from having them.

The concept of sprints comes from this section of the manifesto – Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Sprints come from the idea of demoing the software to the customer. If we have stakeholders we are working with on this project (that’s from the manifesto too, you are working directly with the users, right?) it works best if you show them the features you are working on so they can see them and give feedback before you move on.

Based on this, we can safely say that a two week sprint probably makes sense if:

  1. You have a stakeholder/customer to demo a feature to
  2. Two weeks is a reasonable amount of time with which to get that work done

And probably doesn’t make sense if those two things aren’t true.

Teams that decide the two week sprint is inviolable end up sizing up or down their work arbitrarily to fit into sprints. Since I work in data teams, it’s very uncommon to have work that requires exactly two weeks. We often have tasks that are extremely quick, often one sitting, and work that is nearly impossible to estimate, such as debugging or large refactors or system implementations. And these portions of work may have many interdependencies on other teams.

If you are constantly scrambling to fit work into sprints, or often have production issues that interrupt them, or are constantly unprepared for the start and end of the ‘sprint’, consider abandoning it altogether. Many teams I’ve worked with use a simple kanban board, size things as small, medium, and large, and never have a sprint at all. Some do weekly planning, some monthly depending on the size of the projects in progress. The main goal is sizing the ‘sprint’ or lack thereof to the work itself and never the other way around.