A gentle (re-)introduction to Scrum, a framework for project teams

Nowadays most agile software development teams use Scrum (side note: Make sure to pronounce “Scrum” with a stone coal accent if you’re part of a Dutch-speaking team.) as a software process model. In practice, teams often deviate from “standard” Scrum. When this happens, it’s technically longer Scrum but ScrumBut; a potentially dysfunctional implementation of Scrum. Having said that, agile can sometimes feel a bit like a cult, so don’t worry too much about it!

This blog describes what an ideal implementation of Scrum looks like according to Jeff Sutherland’s (side note: Jeff is one of the creators of Scrum.) Little Red Book and how it can be applied in a self-managing team of motivated professionals. These professionals don’t necessarily have to be engineers; they could also be other roles, like lawyers, artists, or HR professionals. To keep this blog readable I’ll only use the term “engineer”, but keep in mind it can be anything you like.

Scrum is an empirical framework for managing projects that are executed by teams of knowledge workers. Scrum ensures that teams can work flexibly, efficiently, and effectively.

The work is organised into fixed periods called sprints, which typically last two to four weeks. During each sprint, a team works on tasks (backlog items) that the team has agreed upon prior to the start of the sprint. The sprint goal is achieved by completing all tasks. These tasks are listed on prioritised to-do lists, which are called backlogs.

The Scrum framework distinguishes between several types of roles, rituals, and artefacts.

A Scrum team typically consists of up to ten members. Together, they possess all the skills necessary to do the work. The team as a whole is responsible for what is delivered. Additionally, the team is self-managing, determines who works on which tasks, and when and how it’s done.

Some members have a special role within the team:

• Engineers (“the team”) carry out the work. They are also collectively responsible for planning and its execution, the quality of their work, and ensuring that everyone sticks to their commitments.

• The product owner represents the customer. As the owner of the product, they have the authority to decide what the product (or the end result) should look like. The product owner is responsible for maximising the value created by the Scrum team, for example, by conceiving, describing, prioritising, and communicating tasks to the team and other stakeholders. A product owner may choose to delegate these tasks, but always retains ultimate responsibility.

• The Scrum master coaches the team in consistently applying Scrum to ensure that it always delivers maximum value. Additionally:

  • They ensure that the team can carry out its work at all times, for example, by organizing Scrum rituals and removing impediments. Impediments can literally be anything: external distractions, team frustrations, broken chairs, and so on.

  • They help the product owner manage and fill the backlogs. Additionally, they facilitate collaboration with stakeholders.

  • They advise the organisation on the use of Scrum and empirical methods, and remove barriers between stakeholders and various Scrum teams.

The Scrum framework includes five rituals. Each of these rituals is designed to maximise transparency in the work and enable the team to perform at its best.

Work is carried out in sprints that may last one month at most. Each sprint is kind of like a mini-project. Once a sprint has started, the content of the work should not change unless there are compelling reasons to do so, such as new insights (major impediments, change of plans). Once a sprint concludes, a new one is started immediately. The sprint progress can be monitored using burnup or burndown charts.

The tasks that need to be carried out are determined by the team during the sprint planning meeting. This is done using the product backlog, which acts as the team’s long-term to-do list. First, the product owner tells the team how they want to improve the product. This enables the team to establish a sprint goal and determines which and how many tasks will be completed during the sprint. The sprint planning is also supposed to be the meeting in which tasks are clarified, but in practice this is often done in separate refinement meetings.

The sprint progress is discussed in the daily scrum (often incorrectly referred to as the “stand-up meeting” (side note: Because for most people this was the only meeting that required participants to stand around a board of some sorts.)), which takes at most 15 minutes. The team is free to choose a suitable format as long as the daily scrum contributes to progress towards the sprint goal.

The sprint review is the second-to-last ritual in a sprint. The results of the sprint are presented to stakeholders in a workshop-like meeting and jointly evaluated. What has the team achieved, and should things be done differently?

The sprint concludes with a sprint retrospective. In this session, discussions are held on how the work and its outcomes can be improved. For example, the team discusses what went well during the sprint, what challenges were encountered, and how those challenges were (not) resolved. Action items are derived from these discussions and addressed as quickly as possible.

The work that needs to be carried out by the team is documented in a set of artefacts. Each artefact represents a specific commitment.

The product backlog is typically a prioritised long-term to-do list of tasks that contribute to the ultimate goal (the product objective). Any work that the team should eventually undertake is listed here. The product owner broadly outlines what needs to be done and assists the team in understanding their requirements; the team determines precisely what needs to be done and how.

The sprint backlog is a smaller, prioritised to-do list of tasks that must be completed within a sprint to achieve a sprint goal. The sprint backlog belongs to and is primarily intended for the team. It constantly shows the progress of the work. If necessary, the scope of the sprint can be adjusted as long as it doesn’t affect the sprint goal.

An increment is a tangible, visible outcome delivered in a sprint that contributes to the product objective. Work is only considered a completed increment when it meets all quality requirements agreed upon by the team in a definition of done.