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

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/

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 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 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.

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.

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:

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.