5-Minute Scrum Learning

Scrum is a focused yet flexible project management approach that enables teams to work through iterative software development processes. Scrum is empirical, providing teams with a method to form hypotheses about how they think something should work, test it, reflect on the experience, and make appropriate adjustments—when the framework is used correctly.

The structure of Scrum allows teams to combine practices from other frameworks that are meaningful to their environment. In the agile world, Scrum has become the leading methodology for software development. The concept of Scrum is reliable and has been validated by thousands of development teams worldwide. Scrum is best suited for cross-functional teams working in product development environments where there is a large amount of work to be broken down into multiple 2- to 4-week iterations.

Scrum Origins

1986: Takeuchi and Nonaka published their article “The New New Product Development Game” in the Harvard Business Review. The article described a rugby-style approach where “the product development process arises from continuous interaction among a carefully selected, multi-disciplinary team whose members work together from start to finish.” This article is frequently cited as the inspiration for the Scrum framework.

Scrum Values (Scrum Values)

The following principles support Scrum’s empirical nature:

Transparency
Teams must work in an environment where everyone knows about the challenges faced by other team members. Teams expose issues internally—often long-standing problems—that hinder team success.

Inspection
The framework includes frequent checkpoints that allow teams to reflect on how their processes are working. These checkpoints include the Daily Scrum and Sprint Review meetings.

Adaptation
Teams continuously assess progress and adjust those items that seem ineffective.

Development Team (Development Team)

Product Owner

The Product Owner is a role responsible for managing the product backlog to achieve the expected outcomes the team aims to deliver.

The Product Owner role exists in Scrum to address the challenge of multiple conflicting directions or a lack of direction faced by product development teams in deciding what to build.

Scrum Master

The Scrum Master is responsible for ensuring that team members live the agile values and principles and follow the processes and practices the team agrees to use.

The title was originally used to denote a Scrum expert who could guide others.

This role typically has no formal authority. The person in this role must lead from an influential position, usually adopting a servant-leadership stance.

Development Team
The Development Team consists of those who deliver a product increment within a Sprint.

The primary responsibility of the development team is to deliver an increment that creates value in each Sprint. How work is assigned is determined by the team based on current circumstances.

Scrum Artifacts

Product Backlog
The Product Backlog is an ordered list of all possible changes to the product. Items on the Product Backlog are options, not commitments—being on the list does not guarantee delivery.

The Product Owner continuously maintains the Product Backlog, including its content, clarity, and ordering.

Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for delivery during the Sprint, along with the tasks the team identifies as necessary to deliver those items and achieve the Sprint Goal.

Increment
The Increment is the set of Product Backlog items completed at the end of a Sprint that meet the team’s Definition of Done. The Product Owner may decide to release the Increment in a future Sprint or build upon it.

Definition of Done
The Definition of Done is a consensus among the team on the criteria that a Product Backlog item must meet before it is considered complete.

Scrum Events

Sprint
A time-boxed event of one month or less, during which the team delivers a potentially shippable product increment. Typical characteristics of a Sprint:

• Consistent duration throughout development
• A new Sprint begins immediately after the previous one ends
• The start and end dates of a Sprint are fixed

Sprint Planning (Sprint Planning)
A team begins a Sprint by discussing which items from the Product Backlog they will address during the Sprint. The final outcome of Sprint Planning is the Sprint Backlog.

Sprint Planning is typically divided into two parts. In the first part, the Product Owner and other team members agree on which Product Backlog items will be included in the Sprint.

In the second part of Sprint Planning, the team determines how they will successfully deliver the identified Product Backlog items as part of a potentially shippable product increment. If this is their practice, the team may identify specific tasks required to achieve this. The selected Product Backlog items (if applicable) and the identified tasks form the Sprint Backlog.

Once the team and Product Owner agree on the scope of the Sprint based on the description of the Product Backlog items, no additional items can be added to the Sprint Backlog. This protects the team from scope changes during the Sprint.

Daily Standup (Daily Scrum)
The Daily Scrum is a short (usually no more than 15 minutes) meeting where the team coordinates activities for the next day. The Daily Scrum is not intended to be a status report or a problem-solving session.

Sprint Review
At the end of the Sprint, the entire team (including the Product Owner) reviews the Sprint’s results with the product stakeholders. The purpose of this discussion is to review, demonstrate, and possibly allow stakeholders to use the Increment to provide feedback. The Sprint Review is not meant to deliver a status report. Feedback from the Sprint Review is incorporated into the Product Backlog for future consideration.

Sprint Retrospective
After the Sprint Review, at the end of the Sprint, the team (including the Product Owner) reflects on the previous Sprint and identifies adjustments they can make in the future. This retrospective results in at least one action item included in the next Sprint’s Sprint Backlog.

5 Core Values

• Openness
• Respect
• Courage
• Focus
• Commitment

Lifecycle

Scrum is a framework that allows development teams to flexibly respond to changing circumstances. The framework provides enough control points to ensure teams do not deviate from expected outcomes and can identify and address issues and adjust processes while work is still in progress.

The Scrum lifecycle begins with a prioritized backlog, but it does not provide guidance on how to develop or prioritize the backlog.

The Scrum lifecycle consists of a series of Sprints, culminating in a potentially shippable product increment. In these Sprints, all activities required for product development occur on a small portion of the overall product. Below is a description of the key steps in the Scrum lifecycle:

1. Create the Product Backlog.
2. The Product Owner and development team conduct Sprint Planning. In the first part of Sprint Planning, the Sprint scope is defined; in the second part, the plan for delivering that scope is established.
3. As the Sprint progresses, the development team performs the necessary work to deliver the selected Product Backlog items.
4. Every day, the development team coordinates their work in the Daily Scrum.
5. At the end of the Sprint, the development team delivers the selected Product Backlog items from Sprint Planning. The team holds a Sprint Review to demonstrate the Increment to the customer and gather feedback. The team and Product Owner also reflect on the Sprint’s progress so far and adjust their process accordingly in the Retrospective.
6. The team repeats steps 2–5 until the desired product outcome is achieved.

Key Benefits

Scrum makes a significant contribution to the software development field by offering a simple yet effective way to manage the work of small collaborative teams involved in product development. It provides a framework and a set of simple rules that allow for an appropriate level of planning, work control, risk identification and mitigation, and problem identification and resolution.