What is a Scrum Sprint?

Characteristics of Scrum Sprints

The following characteristics define a Sprint:

• All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective, takes place within Sprints. This makes the Sprint practically a container for the other 4 events.
• Every Scrum Sprint starts with Sprint Planning. There the Sprint Goal is defined and it is determined which Product Backlog Items will be included in the Sprint Backlog and realised in the Sprint. Afterwards the Scrum Team commits itself to the Sprint Goal.
• The result of the Sprint is a potentially shippable Increment – also called Increment of Potentially Shippable Functionality. Theoretically, several deliveries per Sprint are possible, but only one Increment to the end of the Sprint is mandatory.
• A Sprint always has a constant duration – also called Timebox. According to the Scrum Guide the duration ranges from one week to a maximum of one month. This relatively short period of time is an essential difference to the classical iteration, which does not define a standardised specification of duration. Also the term as such indicates that it is not a medium or long distance run but a short distance – a Sprint – in the figurative sense. Longer Sprints could increase the complexity and thus the risk of mistakes. Sprints promote predictability by at least ensuring that progress towards the Sprint Goal is continuously monitored and adjusted. At the same time, the financial cost risk is also limited to the duration of the Sprint.
• Every working day, the developers (and, if applicable, the Scrum Master and the Product Owner) meet for the Daily Scrum and discuss the completed and upcoming tasks to achieve the Sprint Goal, as well as possible obstacles in the work. The status of the tasks is often visualised via taskboard.
• At the end of the Scrum Sprint, a Sprint Review is conducted, in which the team presents the completed work results to important stakeholders (and as the representative of the stakeholders to the Product Owner).
• After the Review a Retrospective is carried out.There the Scrum team reflects on the last sprint and looks at which aspects should be retained in the next sprint and which should be left out.

Rules for Scrum Sprints

In addition, the following rules or points should be considered:

• During a sprint no changes are made that could endanger the Sprint Goal.
• Quality Goals are not reduced.
• The scope can be negotiated between the product owner and the developers as soon as new findings and lessons learned are available.
• The Product Owner is the one who could abort a Sprint if the Sprint Goal turns out to be obsolete.
• Ideally, the developers should remove possible impediments on their own. This is a step towards self-management. The Scrum Master only helps if necessary.
• The Burn-Down-Chart or alternatively the Burn-Up-Chart are tools to visualise the progress within a Sprint.
• The speed of the development team per sprint is called Velocity. However, the Goal in Scrum is not to increase the Velocity, but to use it as an aid for future Sprint Plannings.
• A new Sprint starts immediately after the completion of the previous Sprint.

Sprint Duration

Who determines the duration of the Scrum Sprints? Ideally all participants together, i.e. the developers, the Scrum Master and the Product Owner. But what happens if opinions differ about the duration – who should decide then? Here opinions vary:

• The Product Owner is predestined to determine the duration because he “knows” the customers and users and knows in which frequency they expect new Increments. In practice, however, it often happens that deliveries in a weekly or monthly rhythm overtax organisations; the Increment at the end of the Sprint does not have to be delivered, but should only be “deliverable”. This means: if the customer expects new Increments in short cycles, then the Product Owner could determine the duration.
• The Scrum Master is predestined to determine the duration, because ideally he knows the developers and their ability to create deliverable added value best. It is of no use if the Product Owner defines a duration in terms of the business, but the team is unable to do so. It is also possible that there are technical contexts and necessities that have an influence on a suitable duration.

Ultimately, it comes down to the question: what does the market or the customer want and what can the team develop in the long term with the appropriate quality? Every organisation must find the answer to this question for itself.

Naming of Sprints

There are several ways to name Sprints. In practice, it has been shown time and again that a certain amount of creativity helps to strengthen the team or to build a team:

• Usually Scrum Sprints are numbered, starting with Sprint 0, then Sprint 1, Sprint 2, etc.
• Sprints could also be named after films or songs. In such a case, it would only be important that the film title matches the Sprint Goal, for example, and not that the Sprint Goal is selected to match the film title.
• Alternatively, beer brands, artists, characters from computer games or animals can be used as name givers.

Allowed is what you like.

Use of different sprint metrics

In many companies, velocity or the velocity factor is used as a measure for planning sprints based on story points. In addition, there are numerous other agile metrics that could be used:

👥 Attendance rate: the percentage of team members who attend daily meetings or other team events.

📉 Backlog Health: a measure of the overall health and efficiency of the team’s backlog, including factors such as backlog size, obsolete items and progress towards completion.

👏 Customer Satisfaction: a measure of how satisfied customers are with the team’s work.

♻️ Cycle Time: the time a team needs to complete a task from start to finish.

💥 Defect density: the number of defects per unit of work.

📌 Escaped Defects: the number of defects that make it into the final product despite the team’s efforts to avoid them.

📈 Flow Efficiency: the percentage of time a team is actually working to create value, rather than waiting for resources or approvals.

🕖 Lead Time: the time it takes from a client requesting a task until the task is delivered.

🔨 Mean Time To Repair (MTTR): the average time it takes to repair a defect.

❓ Percentage of Rework: the percentage of work that is reworked due to defects or other problems.

💪 Team morale: a general measure of the team’s commitment and motivation, determined through surveys or other forms of feedback.

🕧 Time to Market: The time it takes a team to bring a product or feature to market.

🕝 Time to Value: the time it takes a team to deliver tangible value to a customer.

📊 Work in Progress (WIP): the amount of work currently in progress in the system. This metric can help teams recognise bottlenecks and reduce multitasking, especially in combination with the WIP limit as the maximum number of tasks a team can work on at a given point.

Certainly this list can be expanded. The Scrum Guide does not define a metric, so organisations can decide which metric or metrics are most useful for their work.

Impulses to discuss:

The Sprint length is always a compromise between “having to react quickly to changes” and “being able to work in peace”.

Can you imagine situations in which so-called “Nested” Sprints can be useful?

Notes:

Jeff Sutherland, in his book “Scrum: The Art of Doing Twice the Work in Half the Time“, explained how the term Sprint came about: “„… And so my team embarked on what we called ‚Sprint‘. We called them because the name evoked a quality of intensitiy. We were goint to work all out for a short period of time and then stop to see where we were“. 

Here you can find additional information from our blog:

What does t2informatik actually do? One click and you'll know.