The Scrum process explained

Agile Scrum process explained

Technically speaking, Scrum is a framework, not a process or methodology. That’s what the Scrum Guide tells us.

But if we accept that a process is a set of repeatable, ordered steps designed to achieve a goal or produce an outcome, there is no doubt that Scrum at least includes a process.

The iterative, Agile process that Scrum includes revolves around a concept known as the sprint:

• A sprint is a product development effort that lasts for no more than a month.
• Each sprint includes a well-articulated goal developers work to achieve.
• When one sprint ends, a new Sprint immediately begins.
• Sprints are repeated ad infinitum until the product development effort comes to an end.

The iterative Scrum process flow

The aim of each Sprint is to create something tangible and of value that will become part of the finished product. These tangible elements of value are known as increments.

This is why Scrum is said to be both iterative and incremental.

• When one sprint ends, a new sprint begins. That makes Scrumiterative.
• Each sprint adds a something to the final product. That makes Scrumincremental.

What are the Scrum process steps?

To meet the definition of a process, a set of ordered steps is required.

The four timeboxed, ordered steps that the Scrum process defines are as follows:

1. A sprint planning event that marks the start of the sprint. (8-hour timebox)
2. Daily Scrums where developers discuss progress. (15-minute timebox)
3. A sprint review with stakeholders after development is done. (4-hour timebox)
4. A sprint retrospective where the Scrum team introspects. (3-hour timebox)

The sprint retrospective marks the end of the sprint. Once the sprint retrospective concludes, a brand new sprint immediately begins.

The Agile Scrum process flow defines a set of repeatable steps including planning, daily Scrums, reviews and retrospectives.

Scrum is immutable

The Scrum process lays out several requirements that are non-negotiable:

• Events should take place at the same time and place.
• Events stay within their timeboxes.
• Events take place in the order specified.
• No events are ever skipped.

The Scrum framework, as it is described in the Scrum Guide, is immutable. If any part is left out, what you are doing is not Scrum.

Every event listed in this process is required, and teams must perform them in the order and within the time constraints that the Scrum Guide defines.

Is Scrum a framework?

According to the Scrum Guide, Scrum is a framework. The word process never appears once in the Scrum Guide.

Furthermore, Scrum practitioners object vehemently and viciously whenever someone infers that Scrum is a process. Some practitioners accept that perhaps Scrum is a framework that includes a process, but even that point is hotly contested.

The argument put forth by the Scrum community is that the Scrum Guide’s descriptions make it too high-level to be considered a process. Here are some examples:

• It does not tell Scrum teams what tools to use.
• It does not tell Scrum teams how to collaborate.
• It encourages Scrum teams to use external processes.
• It instructs Scrum teams to empirically discover methods that work best for them.

The Scrum Guide describes Scrum as a lightweight, purposefully incomplete framework that “helps people, teams and organizations generate value through adaptive solutions for complex problems.”

At best, Scrum provides an approach to find solutions to complex problems. It doesn’t solve your problems for you.

The Scrum events provide feedback loops for teams and enforce the three Scrum pillars.

Is Scrum an Agile process?

Scrum doesn’t attempt to provide answers to every product development challenge a team will encounter, nor does it place any restrictions on the techniques or methods a Scrum team is allowed to use.

For that reason, the Scrum community fights back hard against anyone who dares to call Scrum a process, or even suggest that Scrum includes a process.

The Scrum community believes practitioners must avoid the mechanical Scrum anti-pattern where teams blindly follow the steps outlined in the Scrum Guide. Such teams do not get the full benefit of Scrum.

Delving into doublespeak

From that perspective, it’s understandable why the Scrum community doesn’t want people thinking of Scrum as a process.

Of course, there are also compelling reasons why parents want children to think of a plate of broccoli as bowl of ice cream, but that doesn’t necessarily make it so.

• Does Scrum describe a set steps to follow? Yes.
• Must those steps be performed in order? Yes.
• Are those steps designed to generate some form of output? Yes.
• Must those steps be performed repeatedly and iteratively? Yes.

If the definition of a process is a repeatable set ordered steps performed to produce an outcome, then it certainly seems hard to argue that Scrum, at the very least, contains a process.

The vast majority of the 14-page Scrum Guide is dedicated to describing this process. One might reasonable argue that Scrum is in fact a process, not simply a framework — but be prepared for a fight if you ever describe it as such.

What is Scrum?

The debate over whether Scrum is a framework, methodology or an Agile process, along with debates over whether Scrum is a process or whether Scrum is a framework that includes a process tend to be unproductive.

Scrum describes itself as a simple, lean, incomplete framework, and that’s a good-enough description.

Scrum simply describes the best practices any team should do if they want to work efficiently and effectively, and uphold the Scrum pillars of transparency, inspection and adaptation.

Scrum may not work for everyone, but everyone should at least give Scrum a try.

Scrum is often described as an Agile process or framework, although the word Agile never appears in the Scrum Guide once.