Sprint length – short or long?

Sprint length: 1, 2, 3 or 4?

How long is the sprint in your company? How was it determined? In most organisations it is not given much of a thought except for the very rudimentary aspects. In some companies it is as short as 1 week, in others it is up-to 4-6 weeks, the most common being 3 weeks in duration in mid-sized to large software companies. Whilst a sprint length of 3 weeks works well for most cases, one size does not fit everyone.

Agile does not encourage lack of planning. The manifesto only says that processes should not be a burden, but it does not mean lack of planning and thoughts. The length of the sprint should be a result of reasoning rather than trial and error experimentation.

We bring forth to you some aspects that you should consider when deciding the sprint length.

Complexity of product

Complexity of the business domain and the product has to be considered for determining how long the sprint will be. If the complexity is high, more time will be needed for understanding and breaking the complexity into simpler tasks. This not only applies to the development team, but also to product owners and scrum masters who have to support the team and also testers who have to come up with the right test cases.

It is important to identify the difference between a truly complex domain and complex code resulting from bad coding practices and architecture. While the former cannot be avoided, the later should be rectified as soon as possible.

Room for improvements and rectifying errors

We know that a sprint is exactly what it literally means – a rush to the finish date to deliver code. However, to deliver quality code, there needs to be enough time in the sprint to refactor code, make improvements to reduce complexity, improve test coverage etc. Without focus on quality, sprints will only be a race to failure.

If a code review happens before any commits to the master branch, a sprint also needs to include time for code review meetings and time to address the comments from the code review.

There needs to be some room for errors as well. Development of software is a science and does not always go according to a script. In situations like that, if the errors are small enough, they should be rectified in the same sprint.

Size of the team and company

The more the size of the team, the more conflicts there will be in the code at the time of merge. In a large team, it is quite common to see the ownership of different modules lie with different people. Good communication, handling the merge issues and making sure the system still passes all sanity checks takes significant time.

In bigger companies, a large number of scrum teams will contribute to the same sprint. Managing work dependencies between the teams could be Herculean task. When some of these scrum teams fail to deliver as promised, many other teams that have already completed their work would be impacted as well. In the worst case, few of the teams would have to undo some of the work already completed during a sprint.

It is for activities such as the above that the structure and dependencies between the teams need to be understood before deciding the sprint length. A longer sprint provides opportunities to handle the issues better.

Overhead of meetings

First lets accept the fact that meetings can’t be avoided, they can only be minimised. The type of meetings to avoid are the ones where at the end of the meeting, there are no concrete action points and another meeting is called for!

And then there are other types of meetings such as architecture discussions, product backlog grooming, sprint planning, retrospectives etc. They are absolutely essential for proper functioning of the team and delivering quality product. However, if possible, the time spent on these should be minimised without compromising on quality and output of meetings.

A rough estimate of the time spent per sprint in meetings should be tracked so that these overheads are factored ahead of the beginning of the sprint.

Definition of done

Importance of a good Definition of done(DoD) can’t be stressed enough. Many a times near the end of the sprints, developers are asked to skip the DoD just to make the delivery happen within the sprint closure. This practice should be avoided at all costs. If the sprint is too short to have room for DoD, more time needs to be allocated. No code should ever get into the master branch without adhering to the DoD.

Too little delivered

We have seen instances where all the aforementioned aspects were considered, but the feeling at the end of the sprint was that very little progress was made and deliveries were insignificant. Quite obviously, a longer sprint is needed to deliver more features or bigger features.

Feedback

Does your product need to have shorter feedback cycles? Or is it more important to show “significant progress”? Not all organisations work the same way regarding this aspect. Although in an ideal scenario you want the organisation to adapt an agile approach from top-down, it is generally not the case in most companies where software is not the main business.

Pressure

There are many scrum masters who believe a shorter sprint works better because it creates a pressure on developers to deliver sooner and more frequently. However, we disagree with such a philosophy if the sole objective is to create pressure on developers. It indicates a culture where developers are not trusted. You would expect the entire team to be always motivated and raring to work, else it indicates a different core issue that needs to be identified and resolved.

Recommendation

Our recommendation is that you start with a 2 week sprint cycle. Observe and tune it for a few sprints. After you have learnt enough about how the team is performing, you could decide if it is working well for you, else you could either decrease it to 1 week or increase to 3 weeks as appropriate. We suggest not to make your sprints 4 weeks long as it is too lengthy a period to have high focus and drive.