Scrum framework consists of 5 events (listed below) that are time-boxed and they help to minimize the need for other meetings. They also create consistency which improves efficiency of the work.
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
The next 5 posts will be describing each of the 5 Scrum events in detail.
In my opinion, Scrum events help to organize the structure of each iteration. That’s how we can create a safe work environment and trigger creativity of the team.
Based on the Scrum Guide:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product Increment is created.
The best way to imagine what is the Sprint in Scrum is using the sprint’s sport analogy. As we all know, sprint is a short distance run, typically focused on quickly reaching the goal.
That’s exactly how the Sprint looks like in Scrum. It is quite a short time period (maximum one month) focused on achieving the goal crafted at the beginning during the planning session.
It is important to keep Sprints short to be able to adjust to the changing world and avoid the risk of increased complexity. From my perspective, it also helps to keep focused on the goal.
Imagine that you are running a short distance - you can see the finishing line and it motivates you to run faster. Long distance running requires much more planning. We don’t want to use all energy at the beginning, so it needs to be accumulated till the end. It’s easy to make that mistake - use all power when we start and be too tired at the end.
Development of the product is similar, we don’t want to make plans too far in the future, because it increases the risk of failure. That’s why the Sprint in Scrum is short enough to see the horizon/Sprint Goal, but long enough to create releasable product increment.
Scrum promotes an iterative approach which means that all activities are done in cycles. During Sprint we discover what is working, what should be changed and we adjust it. The next Sprint starts immediately after the previous one and we can use the knowledge that we gained in the previous Sprint.
The main benefit of short cycles is the opportunity to get early feedback from stakeholders and adapt to the market.
Scrum is a framework and I imagine the Sprint as a frame that consists of everything else. During the Sprint, Scrum Team is focused on the current iteration and all actions are referring to the current Sprint:
- Sprint Planning - time for planning the whole Sprint
- Sprint Goal - what we want to achieve during the Sprint
- Sprint Backlog - work items planned for the Sprint
- Daily Scrum - plan for each day of the Sprint
- Sprint Review - to discuss what was done during the Sprint
- Sprint Retrospective - inspection of what was good and what should be improved based on the Sprint
As you can see all actions are focused on the current iteration - the Sprint.
Of course the Product Owner needs to have some high level idea about the whole development of the product and other Sprints. That’s why he or she creates the Product Backlog, that includes all work items related to the future change of the product.
It is important to remember that Product Backlog is flexible and can be adjusted, changed, but Sprint Backlog is more fixed. It can be clarified, but it needs to be agreed between the Product Owner and Development Team.
Changes that could negatively impact the Sprint Goal or quality goals are not allowed during the Sprint.
In Scrum it is allowed to cancel the Sprint if Sprint Goal is out-of-date due to the technology change or different market situation. I would say that it is a really rare situation, but it can happen and it can be done only by the Product Owner - the only person who has authority to cancel the Sprint.
From a technical perspective when Sprint is cancelled, “Done” work items need to be reviewed. If they are potentially releasable, they can be accepted by the Product Owner. The approach related to other incomplete items is similar like at the end of a normal Sprint. They go back to the Product Backlog and Development Team will need to re-estimate them.
To sum up, the Sprint is an event in the Scrum framework that can take maximum one month.
It helps the Development Team to focus on the work that needs to be done and achieve Sprint Goal. It is also the frame for all other events, actions and definitions in the Scrum.
Cancellation of the Sprint is possible, but it is uncommon and it can be done only by the Product Owner.
I hope that this post helped you to understand the basic idea of the Sprint. I will continue describing all other Scrum events in my next posts.
Join our community
Sign up for newsletter to get the latest news.