Ideal scrum sprint length

User Story

As a <New Team Starting Scrum>

We want to <Choose the sprint length>

So that we can <Deliver valuable increment of product> in each sprint.

How do the team decide the sprint length for their scrum team? The scrum guide only prescribes the sprint length to be no more than a month. So how to choose between 1,2, 3 or 4 week sprint? By going back to the scrum value of self-organising team and scrum foundation - empirical process theory.

Scrum activities

Scrum is iterative development process and Sprint is the iteration. This means all the activities required for the sprint has to be done in each iteration.

1. This means the team has to first do the sprint planning to commit to top value items that they feel comfortable to deliver in the current iteration.
2. They then work on those items while getting feedback from the product owner to get them done.
3. At the end of the sprint, the team have the review with Product Owner and Stakeholders to inspect the delivery and note the things to adapt.
4. They also do a retrospective as to what went well and what didn’t in the iteration.

Apart for the sprint activities the team will have to help the product owner estimate new items and refine the backlog items. There would be some other activities outside the planned sprint (this should off-course be considered in team capacity)

Shorter or Longer sprint

With the commitment to delivering the increment and following the scrum activities, the team has to decide if they prefer, Shorter sprint - 1 or 2 weeks or Longer sprint - 3 or 4 weeks. The team has to choose what works best for their environment.

Shorter sprint are better for feedback, however they require all things to synchronise and churn quickly - backlog refinement, planning, testing. Longer sprint allow more time to experiment solutions, however longer feedback cycle and increase the possibility of unplanned work to creep in.

Some of other things to consider we choosing spring length

Are the product backlog items (PBI) clear enough to finish in the sprint?

• Yes - There is enough details on the story and task can be identified in the planning meeting. With little inputs from the product owner the increment can be delivered. Then prefer shorter sprint.
• No - There is details to start analysing the work but would require so trials before deciding on the approach. There are other systems involved which require some to-and-fro for the increment to be delivered. Then prefer longer sprint.

Does the priority of backlog items change quite frequently?

• Yes - There are new requests from stakeholders which are urgent or at times more important than other. Go for shorter sprint.

Inspect the impact of the sprint length.

Shorter sprint

• Is the team struggling to get items done in sprint?
• Are the stories usually too big to be done in the sprint?

Longer sprint

• Is the lead time too big?
• Is majority of the work getting done in the last week of the sprint?

Adapt the sprint length

After a few iterations if the team feels they are not able to provide optimal value - try a different sprint length. Allow few iterations to iron out any initial hiccups. Again, the answer may not be sprint length, there are might be other factors for team might not be delivering as per their expectation. Retrospect with team to identify if there are other impedance.

Originally published on LinkedIn.