The “Perfect” sprint length

In agile methods, we use iteration to respond to changes and try to deliver faster. The most famous example would be Scrum.

Why it is an important consideration for Scrum? How long should the sprint last?

Impacts Of Sprint Length

The purpose of the sprint is to obtain a shorter and better-controlled scope in your development cycles to meet your business needs. The two-week sprint is almost ubiquitous in agile but the Scrum framework is not prescriptive. Scrum only gives an upper limit of one month. The overall duration of a project is on average 6 months, sometimes less.

There is no good or bad sprint length. The duration of an iteration has a certain impact on the team and the organization.

In my point of view, we can distinguish four types of impact of expected changes on the sprint length:

1 — Business impact (risk management)

  • Quick flipping. The priorities can be piloted by business goals. The length of the sprint must be able to respond to the change and business request integration.
  • Fitted scope. That mitigates the risks. How much can we do now? how soon can we get it in front of the users?
  • Follow speed and acceleration of the market. What is the outside world cadence? What if every team’s cadence was an even fraction of the outside world’s cadence?

2 — Technical impact

  • The big problem is the integration of the work of other teams. In Scrum, for example, an increment is potentially deliverable at the end of the iteration.
  • That forces us to improve highly technical aspects. A short sprint impacts technical excellence, technical debt, and quality assurance.
  • Visibility impact. In the context of multiple teams, some deliverables are very expected. A long sprint makes it possible to integrate and work with other teams.

3 — Organizational impact

  • Product Owner inputs. For instance, splitting into small user stories is easier for a one-week sprint length because the scope is reduced.
  • Accelerated learning. Retrospectives could be more effective and efficient in a small sprint.
  • Coordination with other teams or stakeholders. For instance, stakeholders need to be present.
  • Linked cycles. The learning curve stems from iteration pace.
  • The decisional pace imposes its own pace on iterations.

4 — Team & Product management impact

  • Team needs. For instance, how and when to update metrics?
  • Raise alerts early. With a too-long sprint, it could take a long time before an alert is issued.
  • Many meetings and rituals VS fit allocated time to rituals. Will the rituals time be longer if there is less to say?

Why Experimenting With Sprint Length?

Let’s consider one example from my experience. When I first talked about changing the duration of the sprint in one of my missions, people looked at me with big eyes. Subsequently, I continued to nudge the idea changing sprint length was intrinsically and fundamentally related to each product and team development. We must fight to get the sponsors and stakeholders involved. The best way to hone skills is through participation.

After a while the organization accepts the idea of testing, it remains to convince the development team …

Some objections that had in my teams:

  • It’s not a good idea … without arguments.
  • We will not have the opportunity to achieve our goals.
  • We will not have time to do things right.
  • The Scrum events will be too long.
  • It doesn’t match with the agenda of Product owners.

So I asked the team if we could try, with the option of getting back to normal if it would not work or we would not have a visible result.

In another mission, people were telling me it was strongly related to the PO calendars. There is therefore a strong dependence which is probably useless following working environment.

To all the people I asked the question: have you ever tried? The answer was no. If you hear objections from other parts, like “In my team, it’s not possible, because… ”, it’s likely that there is a reluctance to change to improve, change to learn. Not very agile isn’t it?

So why not test a shorter or longer sprint? Rob Galanakis title one of this article “Two weeks is the worst sprint length”. I might be less categorical but one thing is certain, we must not refrain from experimenting, identifying unnecessary dependencies, exploring alternatives, and innovating. It’s the learning climb for the whole team. If we miss, we will have at least tested, with a reduced cost. And most importantly, learned things.

According to Thomas Watson, IBM’s founder, “The way to succeed is to double your failure rate.”

Fail fast, learn fast.

Conclusion

If a team doesn’t want to question the length of a sprint, it’s probably not agile enough.

Don’t block the empirical process control. Don’t forget to “Inspect and adapt.”

The “right” sprint length should balance the Product Owner’s desire to accelerate valuable inputs and the ability of the development team to supply those deliverables.

And for all those who have already mastered this topic, I suggest them some thought experiences: Can you imagine a one-day sprint? Could you imagine varying sprint lengths depending on your goals? What would happen in your context if you completely removed the notion of sprinting or iteration?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store