6.1 The Sprint
The Sprint is the heart of scrum. It is a short agreed iteration, normally, two to four weeks in duration. In this period of time, the team shall develop a usable and potentially shippable product increment. When one sprint has ended, a new sprint starts immediately.
During a sprint, the team does sprint planning, holds daily scrum meetings, does the development work, including testing, and organizes the sprint review (demo for stakeholders and Product Owner and the Sprint Retrospective.
There are some rules to follow during the sprint:
- no changes are made that would endanger the sprint goal;
- there is no decrease in the quality of the goals;
- scope may be clarified and re-negotiated between the product owner and development team, as more is learned.
A sprint is like a very short project, which normally lasts for two to four weeks during which the team needs to make a working product increment. A sprint goal is set for the team know what to develop, and design; a flexible task plan is created to help build the promised product increment. The development work, including testing, is then done and at the end of the sprint, the product is ready.
The reason why a sprint should not be longer than one calendar month, is that if it is too long it is highly likely that changes will happen, the system will get more complex, and probability of risk within software development will increase. The short sprint ensures that the team knows what to build and are able to ensure inspection and adaption of the work that is done toward the sprint goal. In addition, the cost risk is limited with one calendar month.
Can a sprint be cancelled?
The short answer is – yes, a sprint can be cancelled.
However, it is only the product owner who has the power to cancel a sprint. Of course, he can be advised by other stakeholders, scrum master or the team, but it is only the product owner who can take the final decision if a Sprint has to be cancelled.
Cancellation might occur if, suddenly, the sprint goal becomes outdated and/ or it is no longer a business goal; therefore, there is no need for the ongoing development. This might happen if the market situation changes or due to a change in technical conditions; in that case it make no sense to continue the current sprint on the given conditions. In reality, this does not happen often due to the very short sprint iterations where most companies don`t look ahead more than one month.
There might be some of the product backlog items which are completed to Done when a sprint is cancelled. In this case, the normal procedure is as follows: the increments are reviewed, and if some of them are shippable, then the product owner can choose to accept the smaller delivery. The work which is not finished will be placed back in the product backlog and re-estimated.
As mentioned above, cancellations are not common, and can be tough for the development team because the commitment to deliver in scrum is extremely high. It is also costly to cancel a sprint, as everyone has to regroup in another sprint planning meeting to start a new sprint. A good explanation of the cancellation is needed for the development team, so they understand the reason and become ready for full commitment in the next sprint.
