Sprints are timeboxed (1 month or less) iterations that support the interactive & incremental nature of Scrum. Sprint is one of the five events in the Scrum framework. It is a container of all the other 4 events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. To manage the complexity & better predictability, Sprints are generally of consistent durations.
Sprints provide a rhythm to the Scrum framework that enables better predictability as Scrum teams learn how much they can do in a given period. However, in a complex environment, nothing is guaranteed.
Sprint starts with Sprint Planning and ends with Sprint Retrospective. Next Sprint starts immediately after the previous Sprint ends.
An exception to other Scrum events, Sprint timebox doesn’t reduce if the purpose is met. Consider adding more Product Backlog items, process improvement actions from previous Sprint Retrospectives, innovation items, or improving quality.
Selecting the Right Sprint Length
Many Scrum teams struggle with selecting the right Sprint length. Below are few tips for that.
- Business Risk: How long business or Product Owner can wait to get feedback that can help the Scrum Team to make informed decisions. So if the environment is very complex and volatile i.e. priorities are changing very frequently because of changing customer’s needs, technical complexity, or increased competition. In such an environment, it would be better to with a shorter Sprint length..
- Ability to Create “Done” Increment: How much shorter Sprint should be? Scrum Team must be able to create a “Done” increment that is workable, inspectable, and potentially releasable.
- Only rules that applied are: Sprint must not be more than 1 month and for every Sprint you must create a Done increment.
- Real Life Example 1: When I was developing a Digital Web Application for a bank, We started with a Sprint length of 1 month ( 4 Weeks) but soon we realised that we need frequent feedback from stakeholders as rework/waste was increasing. We reduced the Sprint length to 2 weeks and it worked really well for us.
- Real Life Example 2: When I was working for an Automotive company, we started with a 2 weeks Sprints. Very soon we realised that we can’t create a “Done” increment as features required much more time to build and test. We changed the Sprint length to 1 month (4 weeks) and it was a much better rhythm.
Sprint can be canceled however, it is a very rare scenario. The only reason, when Sprint can be canceled is if Sprint/Product Goal becomes obsolete i.e. it doesn’t make sense to keep working on it. It could be because of competition, market, or technical feasibility. For example, for an engineering firm, we were working on in-house software development to meet our unique needs. However, after 4 Sprints we realized that we don’t have enough technical expertise and if we continue we might lose the competitive edge. Hence, the organization decided to buy the product from a reputed vendor and configure the product for our needs.
If the Sprint is canceled, move the not-done PBIs to the Product Backlog and re-estimate and re-plan.
If Sprint Goal can’t be met or is difficult to met or any emergencies have appeared: these are not the valid reasons to cancel the Sprint. In such cases prefer to adjust the scope of work via collaborative discussion between the Product Owner and Developers.