The Sprint is a time-boxed work period, typically lasting from one to four weeks or up to a full calendar month. The goal of a Sprint, called the Sprint Goal, is determined during Sprint Planning. During the Sprint, the developers work to achieve the Sprint Goal, and the Scrum Master works to remove impediments while coaching the developers and Product Owner as needed. Sprints, with their quick feedback and course correction, are not just a part of Scrum, but a catalyst for innovation and adaptation, inspiring teams to adjust their plans in response to customer needs or changes in the environment.

Sierra Agility’s TeamAdvisor feature will help you ensure that your team’s Sprints are planned effectively and start and end precisely when they should.

Sprint Length

Sprints are an essential aspect of Scrum. It is during a Sprint when the developers work on one or more product backlog items before reviewing the product at the end of the sprint during the Sprint Review. Generally, sprints are between two to four weeks and can range from one day to one month, depending on the team’s preference. The goal of the sprint is to deliver potentially shippable increments of working software so that teams can get feedback quickly and make adjustments as needed. This helps minimize waste and keep costs low while promptly ensuring customers get the necessary value and benefits. Furthermore, with a fixed duration, Scrum provides predictable schedules, and planning is easier since teams know reasonably well how long it takes to complete each task or feature. Sierra Agility has several built-in features to help your teams set the right sprint length.

Sprints have a maximum length of one calendar month and have no minimum size.

Two things generally drive sprint length:

1. Team preference – if the team prefers to take their time and go over all details carefully, they may lengthen the sprint to ensure that they deliver the highest quality of work. On the other hand, if the team is experienced with an agile mindset and prefers to move quickly, they may shorten the sprint length to leverage incremental development and increase feedback. Ultimately, it’s up to each team to determine what works best for them based on their preferences and capabilities.
2. Product Backlog volatility – product backlog volatility can have a direct effect on the length of a sprint. If the product backlog changes frequently and unexpectedly, it can cause disruptions in the workflow and overall timeline of the project. This can lead to difficulty accomplishing the Sprint Goal, as more time and effort will be needed to address the changes. Additionally, these changes may require that some tasks already completed during one Sprint be revisited during future sprints, resulting in an overall lengthening of the project’s timeline.

Canceling a Sprint

Canceling a Sprint may be necessary at times. Cancellations occur when the Sprint Goal becomes obsolete. Causes for a sprint goal becoming obsolete can include changes in the market, new customer requirements, external regulatory changes, or technological advancements. Additionally, an organization’s strategic goals and objectives may shift over time, causing sprint goals to become irrelevant. Finally, changes within the team or team dynamics may require the sprint goal to be revised mid-sprint.