The Sprint is the fundamental unit of work when using Scrum. Any product development effort using Scrum is, therefore, divided into Sprints. Sprints are fixed in length so that the team has a predictable amount of time available to them to complete the work, which in turn assists in both short and long-term planning. By making every Sprint the same length, the Scrum Team learns its own capacity for work. If the Sprint length changes, the rhythm of Scrum is broken and the team will have to relearn its capacity which usually takes at least a few Sprints. If Sprints are rarely the same length, then the Scrum Team will struggle to do any reliable planning.
The Scrum Master of the Scrum Team has the primary responsibility for helping the team create the rhythm of regular Sprint lengths. The Scrum Master needs to ensure the meetings that occur at the beginning and end of the Sprint are scheduled for many Sprints well in advance with specific dates, times and locations. For example, if the organization is using Microsoft Outlook, then these meetings should be blocked off in all Team Members’ calendars with those people as required attendees. If the team’s Sprint length is meant to be two weeks, and if Sprint Planning is Monday morning, then every other week there should be a meeting reserved in the calendar for all Scrum Team members for Sprint Planning, likewise for Sprint Review and Sprint Retrospective meetings. This basic administrative approach is a foundation to correcting an irregular Sprint length.
As well, the Scrum Master needs to facilitate the team to enable preparation and effective execution of the Scrum process within the Sprint to ensure regular length. For example, the Scrum Master should ensure that the Product Owner is constantly refining the Product Backlog so that it is ready for each Sprint Planning meeting. Similarly, the Scrum Master facilitates the Scrum Team to prepare for each Sprint Review so the product Increment is ready to be demonstrated.
One common pitfall is the temptation to delay the Sprint Review meeting if the product is not ready or if stakeholders cannot attend. This should never be an excuse for delaying the Sprint Review. Instead, the Scrum Team should demonstrate whatever is ready (even if nothing is ready!) and use the Retrospective to come up with ways to avoid that problem in the future. Similarly, if some stakeholders cannot attend the meeting, hold it anyway and rely on the feedback from those who are able to attend… even if that is just the Product Owner.
Time-boxing the Sprint to have a consistent length is meant to put pressure on the team and the organization to have reliable delivery of product Increments.
Sprints best have consistent durations throughout a development effort. – The Scrum Guide