Practice: Why do we Sprint?

Posted on by Oliver

Scrum knows the sprint as a central element: “Sprints are the heartbeat of Scrum, where ideas are transformed into value.”: But How? And what makes the sprint so special?

How does the sprint work?
A Sprint

  • is as long as the previous one. The sprints are therefore of constant length.
  • is maximum one month long. so if necessary also shorter.
  • starts directly after the previous one, i.e. without gaps: everything happens in the Sprint.
  • can be aborted if the sprint goal is no longer achievable.
  • follows certain rules:
    • Nothing may be changed (added/modified/excluded/…) within the sprint that endangers the sprint goal.
    • The quality must not decrease.
      So, in concrete terms, even if things get hectic towards the end of the sprint, we must not abandon code reviews, testing, etc.
    • The sprint content is specified and refined if necessary.
      So not every detail has to be predefined in the planning. Yes, new questions or ideas should even arise during the Sprint.
    • In case of new insights, the content or scope of the Sprint can be updated with the Product Owner.
      For example, we might realize that something planned already exists in the software in a similar form, so we don’t need to implement it anymore.


Why Sprint?
In a nutshell, it’s about avoiding the planning fallacy.

  • Regularly
    Like our heartbeat, Sprint is regular and predictable: Always the same length and consecutive. Content always of the same structure: planning, dailies, review, retrospective.
    • Focus on sprint content
      Thanks to this regularity, we can focus on the content, the value creation (user value), without having to worry about the process or the workflows.
    • Mental relief
      This ability to focus reduces the complexity and thus the mental load of everyone involved.
    • Learning from the past
      This regularity also facilitates the further use of our findings for the future due to fixed framework parameters, especially the fixed observation period.
      With this knowledge, it is possible for us to decide, for example, how much we want to achieve in the following sprint (sustainable pace).
  • Focus on sprint goal
    Beyond the described focus on content, usually stories, the sprint goal enables us to focus on the most important sprint content.
    This gives us, for example, the flexibility to decide which sprint content is important and which can be omitted: We do not have to implement all stories, but can decide anew in the sprint. For further advantages of the sprint goal see: “Practice: Is this a good sprint goal“?
  • Manageable, therefore plannable
    The maximum time duration of one month or less makes planning possible in the first place: this reduces the scope in which time, costs and risks can be underestimated.
    Planning over longer periods of time has proven to be too error-prone in practice (see also “Practice: Pre-Planned Sprints“)

What is a sprint not?

  • A race
    The term sprint is risky because it implies racing, that is, fast processing of tasks. However, the sprint does not bring a tool that enables us to type faster. At most, the time-saving effect of the clear process favors speed.
    However, the main focus of the Sprint is to do the right thing right:
    • The right thing is what the customer needs – which is not necessarily what the customer thinks they need (“If I had asked people what they wanted, they would have said: faster horses.”, Henry Ford) and
    • correctly means: incrementally, in consistent quality and as direct and regular an exchange as possible with the customer or customers: Loosely based on Henrik Kniberg’s skateboard-to-car image:

Ultimately, we are then better (and possibly seem “faster”) by not doing a lot of things (“saying no”), for example, because we only do the most important things and then get feedback: So we don’t do anything unnecessary (that we later have to drag along, rebuild or revert) and don’t build up technical debt that is hard to uncover afterwards (lost knowledge of error origins, error overlap, etc.).

  • A static story box
    Since the team’s promise (commitment) is related to the sprint goal, the sprint content is by no means static: it can and should be changed if necessary. Especially if necessary to achieve the sprint goal.

Feedback
If you have any comments, ideas, suggestions or other feedback about this article, feel free to send me an email at Feedback[at]scrummastersmind.com.

Sources: