5.1 The Sprint
The Sprint is the heart of scrum, this is where ideas are turned into value. It is a short-agreed iteration, normally, two to four weeks in duration. A soon as one sprint is finished, and conclusion made the next sprint starts.
A sprint contains all work needed to get to the Product goal. 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. All that happens within a Sprint.
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;
- the Product Backlog will be refined whenever needed;
- 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. These short iterations make it possible to predict the progress toward the Product Goal and ensuring the inspection and adaption. Keeping the Sprints short make it more difficult to predicts a Sprint goal and it might become invalid. Longer sprint also increases the complexity and might lead to higher risks. Shorter sprint can also be used to generate more learning cycles. Each sprint can be considered a very short project and a short project has a limit risk of cost and effort.
In agile we have seen lots of different tools to forecast progress, like burndowns, burn-ups or cumulative flows. These can be very powerful tools and might be proven useful, but they cannot replace or stand more important than empiricism. In complex product development and environments, the unknow will happens. So, we can only use what has already happened for analysing and forward-looking decision making.
Figure: Example of Sprint Burn down chart. Sprint Burn-down, Remaining Effort, Day. Remaining, Ideal.
Can a sprint be cancelled?
The short answer is – yes, a sprint can be cancelled if the Sprint Goal becomes obsolete.
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.