Theory "Sprinting"
Sprinting and Sprint¶
As you already know, the Sprint is a Scrum Event - but one of particular meaning. This is because the Sprint is "the container" of the other Scrum Events. That means that all other Scrum Events take place during the Sprint. This is not surprising, because as soon as a Sprint is over, the next Sprint starts - without a break and without the time for anything else to happen "in between".
A central role during the sprint is the "Sprinting". Sprinting is the time when the Increment is actively worked on and developed.
The Sprint Planning Meeting has been completed, the Sprint Goal is known and the Sprint Backlog has been worked out and placed in a clearly visible position for all participants. Now the development work can begin. The Developers can work on the previously defined tasks and approach the Sprint Goal step by step, i.e. in iterations.
To summarise
A Sprint starts as soon as the previous Sprint ends. The Sprint is the container of all other Scrum Events, i.e. during a Sprint different meetings take place and during a Sprint a previously defined Sprint Goal is worked towards.
During each Sprint, Sprinting takes place - between the Sprint Planning Meeting and the Sprint Review. The Daily Scrum Meeting is held every day during the Sprinting session.
The objective of a Sprint¶
The goal is not to create the complete product within one Sprint, but to create one potentially deliverable Increment per Sprint. To put it in other words: The Developers create a thin vertical slice of the entire product per Sprint.
A potentially deliverable product.
The Increment at the end of a Sprint should be potentially deliverable - this does not mean that it has to be delivered. It should be possible to publish or hand over to the customer after each Sprint, but it is by no means an obligation to actually deliver the Increment.
What is important during the Sprint.
During the Sprint it is important that the Developers focus on the tasks that are intended for the respective Sprint. Long-term tasks or user stories, Epics or Themes that are still in the distant future have not yet been transferred to the Sprint Backlog and therefore do not need to be worked on yet. Developers should therefore not focus these PBIs.
The duration of a Sprint¶
Since no entire product is to be created within a Sprint, but the "thin vertical slice" must be potentially deliverable, it is important that a Sprint does not last too long, but also not too short. How long a Sprint should be is determined beforehand. When determining the duration, the Product Owner should keep in mind that the Sprint should only last as long as the business risk is manageable. It is also a good idea for the Sprint to last long enough so that other business matters can be synchronised with the Sprint.
However, it is important that intervals (the so-called time boxes) do not exceed four weeks and that - once the Sprint duration is set - the period is fixed. The time periods can only be changed if the Scrum Team decides on this together. However, the Scrum Team must be aware of the fact that changing the time periods makes it more difficult to assess the progress of the project and the quality of the process.
Events and meetings during the Sprint¶
Development intervals are time-boxed¶
A Sprint, like the other Scrum Events, is time-boxed. This means that the event must be completed within a certain time frame. Accordingly, the Sprint ends as soon as the time box has expired - even if the product increment is not completely finished. Even though the Scrum Events have a fixed end due to the time box, this end is not the same as a deadline. A deadline is usually set externally, whereas the time box is set by the Scrum Team itself. Moreover, the Developers are not threatened by external consequences if they do not reach the Sprint Goal within the time box.
The optimal Sprint duration varies from project to project. For complex development projects, however, shorter Sprints are a good idea because
- you can act more quickly if the project is not going in the right direction.
- complexity is reduced.
- the risk is reduced.
Advantage of short intervals
The reason why sprints are limited in time is simple: if the process from idea to finished product is condensed and correspondingly short, problems can be detected and process weaknesses identified at an early stage.
Meeting sequences¶
So far, you have already heard about the following Scrum Events or Meetings:
- Not an official Scrum Event: Backlog Refinement Meeting
- Sprint Planning Meeting
- Sprint
Other meetings that take place during each Sprint are:
- Daily Scrum Meeting, which is held every day during the Sprinting.
- Sprint Review, which takes place after the Sprinting.
- Sprint Retrospective, which takes place after the Sprint Review and before the new Sprint starts.
- Not an official Scrum Event: Release Planning Meeting, which can take place at the beginning of the project.
During the next chapter you will learn more about the Scrum Events you are not familiar with. At this point you will have the opportunity to check the knowledge you have gained so far:
What is the Backlog Refinement Meeting, what is the procedure and who takes part?
The Backlog Refinement Meeting is a regular time slot for reviewing and evaluating the Product Backlog. This involves reviewing the user stories in the Product Backlog, checking their relevance, and whether they still represent the interests of the stakeholders. There is no fixed agenda for this meeting, but a possible agenda could be as follows:
- Sorting and prioritising the Product Backlog Items
- Deleting entries that are no longer important
- Adding new entries to the Product Backlog
- Formulating and adding details to Product Backlog Items
- Summarising Product Backlog Items
- Estimating entries in the Product Backlog (effort estimation)
- If necessary, schedule releases
The Product Owner is responsible for the Backlog Refinement Meeting in his role as manager of the Product Backlog. He is supported by the Developers. The Scrum Master can, but does not have to, be present.
What is the Sprint Planning Meeting, what is its time-box and who takes part?
The Sprint Planning Meeting is the initiation of the following Sprint. During this meeting, the work to be done during this Sprint is determined. At the end there will be a plan that has been created by the whole Scrum Team.
Topics covered:
- Why is this Sprint valuable?
- What can be accomplished in this Sprint?
- How should the selected tasks be completed?
The duration of the Sprint Planning Meeting depends on the duration of the Sprint. The meeting lasts a maximum of eight hours for a maximum Sprint duration of four weeks. This meeting is attended by the entire Scrum Team consisting of:
- Product Owner,
- Developers and
- Scrum Master.
If necessary, representatives of the customer or user may also be present.