Several smaller events make up a Sprint in Scrum. Sprints, in turn, form together a path aimed at developing and releasing a Product. Each Sprint has a specific Sprint Goal and a Sprint Backlog maintained by the Development Team.

What is Sprint in Scrum – table of contents:

  1. Sprint in Scrum – Introduction
  2. Sprint in Scrum Structure
  3. Sprints and the three pillars of empiricism
  4. Transparency
  5. Inspection
  6. Adaptation
  7. What changes to make during a Sprint?
  8. Sprint in Scrum – Summary

What is Sprint in Scrum?

Sprint is the largest of the events in Scrum, which we wrote about in this article. Sprints follow a continuous cycle from the beginning to the end of work on a Product. And each iteration brings the team closer to achieving the Product Goal.

Each Sprint has a specific Sprint Goal to ensure consistency in the work of the Development Team. It takes the form of a business goal and answers the question “Why?”, “To what end?”, or “Why?”.

The workflow of a Sprint is documented in the Sprint Backlog, which lists the work needed to achieve the Sprint Goal. Its detailed description can be found here.

sprint in scrum

Sprint in Scrum Structure

Each Sprint has a specific structure and includes the following events:

  • Sprint Planning – the Sprint starts. During this event, the Scrum Team selects the planned work from the Product Backlog to be done in the new Sprint
  • Daily Scrum – a daily event where Developers plan the tasks for the day
  • Sprint Review – open to Stakeholders, held on the last day of a Sprint. Its purpose is to summarize the Sprint in terms of progress on the Product
  • Sprint Retrospective – the closing event of a Sprint, where the Scrum Team discusses the ways of working and ideas for improvement

The repetition of Sprint events promotes the implementation of good organizational practices. In other words, the Scrum Team implements the routines necessary for effective planning and, while working, draws attention to problems that can be discussed at appropriate events.

Sprints and the three pillars of empiricism

Sprints render the Scrum Team to break down the work on the Product into equal time segments lasting no more than a month. This fixed framework reinforces the three pillars of empiricism:

  • transparency
  • inspection
  • adaptation

We wrote about the three pillars of empiricism and their role in Scrum in more detail here. But today, we will look at how they apply to Sprint and its structure.

What is Sprint in Scrum

Transparency

Splitting the work into Sprints enhances transparency as all the people involved can get the required information about the status of the Product work in each Sprint. Sprint Planning and Sprint Review, the beginning and the end of a Sprint, combined with an update of the Product Backlog, provide all stakeholders with valuable insights into the current status of the Product.

Inspection

By dividing the work into Sprints it is possible to frequently monitor its progress. This promotes the constant identification of problems in two key areas. These are:

  • issues related to the achievement of the Product Goal – at the start and end of the Sprint, i.e. during Sprint Planning and Sprint Review
  • obstacles in the way the Scrum Team works – during daily meetings and at the end of each Sprint, i.e. during Daily Scrum and Sprint Retrospective

Adaptation

Adaptation is a very important part of the Scrum Team’s work, as it allows to solve the problems identified during the inspection. During each Sprint, Daily Scrum and Sprint Retrospective provide a safe space to talk about how to improve the Scrum Team. Implementing proposed solutions happens immediately or at the start of the next Sprint.

Sprint Planning and Sprint Review create a safe space for discussion concerning the Goals and methods to achieve them. A good self-managing Scrum Team successfully figures out what and how to implement for the next Sprint.

What changes to make during a Sprint?

Every Sprint leaves enough space for Scrum Team to improve and improvise the way they work. Therefore, identify what to change during a Sprint. The Scrum Guide does not provide a list of such changes. However, the notion of empiricism provides guidelines to follow and adapt to the way a particular Scrum Team works.

  1. All changes can jeopardize the achievement of the Sprint Goal. According to the first rule, during a Sprint you cannot, for example, reduce the number of to-dos in that Sprint, or significantly change their characteristics. A Sprint is closely tied to the Sprint Goal. Therefore, when the Goal changes, we should abort the Sprint. However, this hardly ever happens as the only reason for a Sprint to fail is when the Objective becomes obsolete. Keep in mind that the decision to terminate a Sprint belongs solely to the Product Owner.
  2. The quality of work cannot be compromised. This rule is intended to prevent work done during a Sprint from becoming an Increment because it does not meet the Definition of Completion. Reducing the quality of work can result in the Sprint Goal being ostensibly met, but the way individual tasks get completed does not meet the quality standards set by the organization or required by Stakeholders.
  3. The Product Backlog can become detailed. While working on a Product, the knowledge about it increases. Therefore the detail of tasks to perform increases naturally. Therefore, it is an acceptable and even advisable change during a Sprint to detail the Product Backlog.
  4. The scope of work may get clarified or renegotiated. This change, like the previous one, involves a growing understanding of the nature of the work being performed. The Development Team can do it in consultation with the Product Owner. However, the basic condition for its introduction is the lack of conflict with principles 1. and 2.

Sprint in Scrum – Summary

Sprint is the cyclic Scrum event that contains all the others. It has a sub Sprint Goal separate from the Product Goal. And the Sprint Backlog is different from the Product Backlog. The nature of Sprints is cyclic. The fixed length of Sprints is conducive to maintaining good workflow practices and nurturing the three pillars of empiricism. During a Sprint, the Scrum Team cannot change its Objective. It can, however, refine the Product Backlog and as knowledge grows, refine and negotiate the scope of work.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Author: Natalia Jaros

View all posts

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing