Ready, Set, Sprint

A new Sprint, i.e. a cycle within which we work as a team, never lasts longer than a month. As a rule, organisations choose the duration in a way that suits the organisation and the team – mainly in weekly cycles. Most organisations choose a duration between two and four weeks. This is also intended in the Scrum Guide. However, it would never last two weeks and three days, for example. Weeks that have already begun are unsuitable.

• Each cycle has a Sprint Goal.
• During the agreed duration, no changes are made that jeopardise the Sprint Goal.
• It is important that the quality does not decrease in the defined time window, but that the developers work permanently on the product at the highest level.
• The team develops the Increment together.
• Meanwhile, the Product Owner works on refining the Product Backlog.
• It is the Product Owner’s task to gain new knowledge about the product, about the requirements, and to pass this on to the Sprint if necessary, provided it does not jeopardise the Goal.

The Actual Duration of a Sprint

How long does a Sprint actually last? This is often an important question in practice to which there is no universally valid answer.

Basically, one can postulate: The higher the uncertainty of the product to be developed or of the customer’s requirements for the product, the shorter the agreed cycles should be. So if a new product is to be launched, if it is not known how it will be received by the customers, if it is not yet clear which features will be of what use to the customer, then it is better to Sprint with seven days – i.e. with the shortest possible duration.

If you know exactly what you want to develop and would rather reduce the administrative “overhead” by having too many Scrum events, then a four-week time window is preferable. Basically, the rule of thumb is: the shorter the duration, the more you limit the risk of costs and the threat of effort due to incorrect development. The more certain you are about the development, the longer the period can be chosen.

The Presentation of Progress

Within a Sprint, there are various ways to make the progress of the development transparent. In general, the stakeholder, who in practice is primarily interested in observing the development of a project, has the opportunity to look at the Sprint Backlog – i.e. the concrete task list of the team. For this purpose, other practices such as a burn-down chart could be used, which shows the progress graphically.

A burn down chart consists of two graphs in a coordinate system, where one graph shows how far one should be in the time frame according to the planning and the other shows how far the team actually is. Here is an exemplary representation:

In practice, the Daily Scrum is often used as an invitation to stakeholders to find out how development is progressing. With its 15-minute rhythm, the Daily Scrum offers the best prerequisites for informing everyone briefly, concisely and efficiently about the concrete status of the current cycle. Of course, it does not always work that the stakeholders can participate in the Daily Scrum.

The Rhythm of a Sprint

The rhythm of a Sprint should not be changed. This is especially important for newly formed teams that may need to test each other first. Once the duration has been set, it remains fixed and is not ended prematurely.

It is an absolute exception and speciality if a Sprint is interrupted or terminated. This only happens if the agreed goal becomes obsolete. The decision whether to terminate and completely reschedule is the responsibility of the Product Owner. He alone has the authority to cancel the sprint.

Example:

Imagine you want to develop an online shop and are in the process of implementing a new feature that allows customers to chat with each other within the online shop. Now the federal government decides to reduce VAT to 16% at short notice. Consequently, you have to take the tax change into account for legal reasons. This would make the agreed goal obsolete and the Product Owner has a valid reason to abort the sprint.

If there is an abort, a Sprint Review takes place immediately afterwards, followed by the Retrospective and a Planning Meeting for the next cycle.

And How Does Sprint Planning Work?

Sprint Planning is a ceremony or event that initiates the Sprint. The team determines what work it wants to do and documents this in the common to-do list: the Sprint Backlog.

In practice, it has proven useful to divide the planning into 3 topics:

• Topic 1: Why is this Sprint valuable?
• Topic 2: What can be done in this Sprint?
• Topic 3: How will the chosen work be done?

Topic 1: Why is this Sprint valuable?

Here it is the Product Owner’s job to propose and present how the product the Scrum Team is working on could increase its value and usefulness in the current Sprint. The Scrum team works together to define a Sprint Goal that communicates and establishes why the Sprint will be valuable to the customers and stakeholders. It is completed before the Planning ends.

Topic 2: What can be done in this Sprint?

In the next step, the developers discuss with the Product Owner which items, which elements from the Product Backlog should be included in the Sprint. The Scrum Team now has the opportunity to clarify open questions with the Product Owner and thus to have prepared the “what” for the Sprint in the best possible way.

By the way, the Scrum Team or the developers do not have too much say in this. They can only advise the Product Owner on the question of prioritisation. The prioritisation of the Product Backlog and the resulting elements for the Sprint Backlog is still the responsibility of the Product Owner. However, within the second part of Sprint Planning, the developers may point out synergy effects or logical changes to the elements to the Product Owner, which the Product Owner can then pass on.

Example:

In his prioritisation, the Product Owner is of the opinion that the wallpaper has to be hung on the wall first and only then will it be covered with paste. Then the developers could intervene with an alternative solution: Stop, our suggestion is to apply the paste to the wallpaper first and then stick it to the wall. Obviously, the objection is justified and the work is more logical and easier to handle.

Topic 3: How will the chosen work be done?

For each Product Backlog item, developers plan the work needed to create the Increment, which is basically the materialised Sprint Goal. The important thing here is that it is done according to the Definition of Done. It often happens that the Product Backlog elements that have been transferred to the Sprint Backlog are broken down into even smaller work items or tasks of a time span of one day or less on the part of the developers.

For example, the task of the example “sticking wallpaper on the wall” could be divided into the following steps

• setting up the wallpapering table,
• applying the paste,
• sticking wallpaper to the wall.

This division and how this Product Backlog item is processed is entirely at the discretion of the developers. Only they determine how to develop the corresponding Product Backlog item in the required quality.

In this context, the term “knowledge-based decision” is often used. Accordingly, decisions are made where the knowledge is available. Accordingly, the Product Owner respects the opinion of the development team.

Notes:

Fabian Kaiser and Arie van Bennekum tell you what happens after Sprint Planning in their joint book Scrum? Frag doch einfach! Klare Antworten aus erster Hand.

This article is an excerpt from the German-language book.

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