Scrum

This cagegory contains the general principles of the Scrum Framework. It contains links to different sources for further knowledge.

The information on this page has been updated according to the 2020 update of the Scrum Guide. You can read more about the changes in our blog.

What is Scrum?

From the Scrum Guide: “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.

Further reading: https://www.scrum.org/resources/what-is-scrum

When to use Scrum?

Scrum is best used when building complex products. When a lot of the product is unknown or unpredictable and needs to be explored. Scrum’s approach helps because of the iterative approach. Short development cycles and fast feedback ensure that risk is reduced.

Working in sprints and delivering value to the customer early creates fast feedback loops. This way you ensure that you stay on the right path while building a product. Thus reducing risk. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

For examples when not to use Scrum please read: https://leanagiletraining.com/better-agile/when-should-you-not-use-scrum/

Scrum Values

Successful use of Scrum depends on people becoming more proficient in living five values:
Commitment, Focus, Openness, Respect, and Courage.

Below is a summary of the five Scrum Values. You can keep reading about the values on: https://www.scrumalliance.org/about-scrum/values

Focus

The Scrum value of focus is one of the best skills Scrum teams can develop. Focus means that whatever Scrum teams start they finish–so agile teams are relentless about limiting the amount of work in process (limit WIP).

Respect

Scrum team members demonstrate respect to one another, to the product owner, to stakeholders, and to the ScrumMaster. Agile teams know that their strength lies in how well they collaborate, and that everyone has a distinct contribution to make toward completing the work of the sprint. They respect each other’s ideas, give each other permission to have a bad day once in a while, and recognize each other’s accomplishments.

Openness

Scrum teams consistently seek out new ideas and opportunities to learn. Agile teams are also honest when they need help.

Courage

The Scrum value of courage is critical to an agile team’s success. Scrum teams must feel safe enough to say no, to ask for help, and to try new things. Agile teams must be brave enough to question the status quo when it hampers their ability to succeed.

Commitment

The Scrum value of commitment is essential for building an agile culture. Scrum teams work together as a unit. This means that Scrum and agile teams trust each other to follow through on what they say they are going to do. When team members aren’t sure how work is going, they ask. Agile teams only agree to take on tasks they believe they can complete, so they are careful not to overcommit.

Scrum Pillars

Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.

Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans.

Further reading on Scrum.org.

Transparency

The emergent process and work must be visible to those performing the work as well as those receiving the work. Artifacts that have low transparency can lead to decisions that diminish value and increase risk. Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Inspection

The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.
Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Adaption

If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

The Scrum Team

The Scrum Team is a small team of people. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. It is a cohesive unit of professionals focused on one objective at a time: the Product Goal.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

You can read more about the accountabilities of the members of the Scrum Team in the Scrum Guide.

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. The Scrum Master is accountable for the Scrum Team’s effectiveness.

“Scrum Masters are true leaders who serve the Scrum Team and the larger organization.”

The Scrum Master is not a secretary for the team. As scrum master you should have a clear vision on what you are supposed to do and what not. You can read more about the Scrum Master accountability in the article about the eight stances of a Scrum Master.

Product Owner

The Product Owner is one person and is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is also accountable for effective Product Backlog management.

Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Scrum Events

There are five Scrum events to help follow the Agile values and principles. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. They are timeboxed events. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.

The Sprint

Sprints are the heartbeat of Scrum, where ideas are turned into value. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints. The Sprint is timeboxed in a fixed length of one month or less.

Timebox: max 4 weeks.

Output: Product Increment

Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.

Sprint Planning addresses the following topics:

  • Why is this Sprint valuable?
  • What can be Done this Sprint?
  • How will the chosen work get done?

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Timebox: 8 hours (for a 1 month sprint.)

Input: Product Backlog, product increment, team capacity, team velocity.

Output: Sprint Goal, Sprint Backlog, plan.

Attendance:

SM: Optional
PO: Optional
DEV: Mandatory
SH: Optional

Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

Idea’s to exectute an effective Daily Scrum:

1 QuestionWalking the board, 3 Questions

Timebox: 15 min.

Input: Progress towards Sprint Goal.

Ouput: Plan for the next 24 hours.

Attendance:

SM: Optional
PO: Optional
DEV: Mandatory
SH: Optional

Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

The Sprint Review is timeboxed to a maximum of four hours for a one-month Sprint.

Timebox: 4 hours (for 1 month sprint.)

Input: Product Increment,

Output: Revised product backlog.

Attendance:

SM: Mandatory
PO: Mandatory
DEV: Mandatory
SH: Mandatory

Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Timebox: 3 hours (for 1 month sprint.)

Input: what happened in the last sprint.

Output: actionable improvements.

Attendance:

SM: Mandatory
PO: Mandatory
DEV: Mandatory
SH: X

Scrum artefacts

The three artifacts of Scrum are the Product Backlog, Sprint Backlog and the Product Increment. These artifacts are accompanied by three commitments. The three commitments bring focus and transparency to the artifacts.

Product Backlog and the Product Goal

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is the long-term objective for the Scrum Team.

Sprint Backlog and the Sprint Goal

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). The Sprint Goal is the single objective for the Sprint. The Sprint Goal creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Increment and the Definition of Done

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Work cannot be considered part of an Increment unless it meets the Definition of Done. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.

Not-Scrum (but valuable)

The following concepts are not required by Scrum. But they are proven useful. It is up to your Scrum Team to adpot and implement practices that they deem useful.

User Storiy and Hypotheses

A User Story is a piece of work that is defined as a small story in a specific manner:

As a < type of user >,
I want < some goal >
so that < some reason >.
This creates a goal to complete for the developer and a context.
Another way to descrive work is to use a hypothesis format. Hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation. It is written as:

We currently believe that <sprint goal or objective> 

will be achieved if we deliver <possible solution>

because customer will gain <customer value>

we know this for sure when we see <customer outcome>

and <value driven metric> changed.

Watch a Youtube video about hypothesis.

Estimates and Story Points

During refinement sessions estimation is done by the entire team. The objective of the estimation would be to add a relative size to the User Story. This will make it easier to determine what can be delivered within a sprint based on the capacity of the team and the past velocity.

Common types of assigning values to sizes of work are:

  • T-shirt Sizes (XS, S, M, L, XL XXL, XXXL)
  • Story points (1, 2, 3, 5, 8, 13, 20, 40, 100, …)
  • Dog Breeds (Chihuahua, Golden retriever, …, Great dane)

Learn more about story points.

Check out this gem for quickly getting estimations: magic estimation.

Not using estimates #NoEstimates

Another way to become predictable is without estimating. Instead breaking stories down as small as possible. Or to similar-size for all items. And then to count stories to estimate.

Learn more about no-estimation.

Flow and limiting WIP (concept from Kanban)

“Flow is the movement of customer value throughout the product development system. Kanban optimizes flow by improving the overall efficiency, effectiveness, and predictability of a process.”
-Daniel Vacanti, The Kanban Guide for Scrum Teams

The idea of flow is to create small backlog items and visualise how they move through the different stages of your development process (e.g. acceptance, development, testing, acceptance.) The smaller the items, the faster they flow through your system.

Limiting WIP (work in progress) is to assign a maximum number of items that can be in any stage of the development process. This makes bottlenecks visible and creates opportunities to improve your process.

Learn more about Flow and WIP limits.

Extreme Programming (XP) Practices

You can check out the section on XP practices in the category Teaching – XP Practices. It lists a few XP practices that you can teach to your team. These sections overlap because XP practices are not Scrum, but can be higly valueable to your team.