Scrum Events #1 The Sprint

Scrum Events #1 The Sprint

May 25, 2020 5 min to read

This is the first post in the Scrum Events series that will help you to understand what the Sprint is and what is its role in Scrum.

#sprint#scrum#scrum events

Share this post on:

Table of Contents

    *This post has been updated as per Scrum Guide 2020.


    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
    • Sprint Planning
    • Daily Scrum
    • Sprint Review
    • Sprint Retrospective

    The next 5 posts will be describing each of the 5 Scrum events in detail. Scrum events help to organize the structure of each iteration. That’s how we can create a safe work environment and trigger creativity in the team.

    Scrum Framework

    The Sprint - Definition & Length

    Based on the Scrum Guide:

    Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

    The best way to imagine what is the Sprint in Scrum is using the sprint’s sport analogy. As we all know, a 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 Sprint 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. 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 our energy at the beginning, so it needs to be accumulated till the end. It’s easy to make that mistake - run too fast when we start and be too tired at the end. Sometimes when we plan our run, we don’t consider important factors, which can change our result.

    Product development works better when we work in short periods of time. It helps to avoid risk related to changes that we didn’t consider. 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 the 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 vision of 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 also to the future change of the product. They also craft the Product Goal to give everyone direction.

    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, changed but that needs to be agreed between the Product Owner and Developers.

    Changes that could negatively impact the Sprint Goal or quality are not allowed during the Sprint.

    Cancelling 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 Developers will need to re-estimate them.


    To sum up:

    • The Sprint is an event in the Scrum framework that can take a maximum one month.
    • Sprint helps the Developers to focus on the work that needs to be done and achieve the 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.

    Share this post on:

    Would you like to read more about education?

    Sign up for the Newsletter & join Let's Scrum it community!

    Sign up
    Newsletter regulationsPrivacy policy