Scrum Overview

Scrum Overview

In Scrum, the project manager is called the Scrum Master, and the project team is called the Scrum Team. There is a Product Owner who prioritizes the features and requirements to be developed on the Product Backlog.

The Scrum methodology uses Sprints to deliver small increments of work and gather feedback from customers.

There are three (3) Scrum pillars:

SCRUM employs an empirical approach (sometimes called empiricism) to adapt to constantly changing customer needs. Empiricism is the practice of making decisions based on actual experience. An empirical approach means working in a fact-based, experience-based, and evidence-based manner—particularly where progress is based on observation of reality rather than on elaborate upfront plans based on extensive initial requirements.

In short, we learn and improve from past mistakes and experiences. The three pillars of Scrum that support empirical process control in every implementation are: Transparency, Inspection, and Adaptation, as shown in the diagram below:

The Three Pillars of Scrum

  • Transparency — A common language and standards to ensure consistency and shared understanding.
  • Inspection — Frequent review of Scrum progress and deliverables to obtain feedback. It is important not to hide the project’s progress.
  • Adaptation — Easily incorporate received feedback and address issues when they arise.

Components of the Scrum Process

The Scrum framework itself is very simple. It defines only a few general guidelines, along with a small set of rules, roles, artifacts, and events. However, each of these components is important, serves a specific purpose, and is critical to successfully using the framework.

The main components of the Scrum framework are:

The diagram below illustrates the key elements of the SCRUM framework. This process has been implemented in the Agile software tool — Scrum Process Canvas.

Scrum Framework
Scrum Framework

Scrum Roles

When an organization decides to adopt Scrum, one of the first things to understand is how Scrum roles differ from traditional project execution roles. Although Scrum has only three primary roles, they do not automatically align with the titles most of us are familiar with. Let’s start with a brief definition of each:

Product Owner

The Product Owner is the Scrum role responsible for representing the business or user community and working with user groups to determine which features will be included in product releases. The primary responsibilities of the Product Owner are:

  • Setting the direction and strategy for the product or service, including short- and long-term goals;
  • Providing or obtaining knowledge about the product or service;
  • Helping the development team understand and interpret customer needs;
  • Collecting, prioritizing, and managing requirements for the product or service;
  • Taking ownership of any responsibilities related to the product or service budget, including its profitability;
  • Determining release dates for product or service features;
  • Answering questions and making decisions daily with the development team;
  • Accepting or rejecting completed features related to the Sprint;
  • Demonstrating the development team’s key deliverables at the end of each Sprint;
  • Being responsible for the Product Backlog.

Scrum Master

The Scrum Master is the facilitator of the agile development team. Scrum is a method that enables teams to self-organize and make rapid changes according to agile principles. The Scrum Master manages the process of information exchange. The primary responsibilities of the Scrum Master are:

  • Acting as a coach to help the team follow Scrum values and practices;
  • Helping remove impediments and protecting the team from external interference;
  • Facilitating good collaboration between the team and stakeholders;
  • Promoting common sense within the team;
  • Shielding the team from organizational interference.

Scrum Team

The Scrum Team (also known as the Development Team) consists of 3 to 9 people who collectively possess all the technical skills needed to deliver the product or service. They are directly coached by the Scrum Master but are not directly managed. They must be self-organizing, versatile, and responsible enough to complete all required tasks.

The Development Team is responsible for delivering potentially shippable product increments in every Sprint—from analysis, design, development, testing, to technical writing. Key characteristics of the Scrum Team include:

  • The team must be self-organizing. All team members must manage their own efforts to complete assigned tasks. In agile Scrum, there is no team leader or line manager figure. Everyone must be committed enough to carry out their activities and contribute to the team’s success. If one fails, everyone fails.
  • The team must be cross-functional. All team members must have the knowledge and skills necessary to deliver a complete, ready-to-use service or product. Experts may be used when needed, but only as coaches to transfer knowledge to the team and fill specific gaps.
  • Product Owner requires business vision. The Product Owner represents the voice of the customer and must convey their needs to the Scrum Master and Development Team. This is typically a full-time role.
  • Scrum Master is not a line manager. They provide the coaching needed for the Development Team and help remove any obstacles the team faces.

Product Backlog

This is an ordered list of all the work to be done on the project. It is presented in the form of stories, commonly called user stories.

User Stories — Different representations of how users interact with the project deliverables (product, service, or outcome). Through user stories, the team identifies the features and functionalities required for the deliverables.

Therefore, the Product Backlog contains prioritized user stories (features and functionalities) for the product/service/outcome. The Product Owner is responsible for prioritizing the backlog.

Note: You do not need to create all stories for the entire project before starting work (this is one of the advantages of the agile approach). Start with the stories you know, and as you learn more, add to the backlog and reprioritize as needed.

Sprint Planning

Unlike the waterfall approach, agile teams do not plan everything upfront. Here, the team plans a little: what is needed for the current Sprint (Sprints are typically 2 to 4 weeks), delivers it, learns from it, and plans the next Sprint again.

The Scrum Team reviews the Product Backlog and selects the number of user stories they can complete within the Sprint timebox. The selected user stories become the Sprint Backlog. The Sprint Backlog represents the goal of the Sprint.

The Definition of Done is also established. The Definition of Done can be thought of as the acceptance criteria for backlog items.

Plan only the work that fits the team’s capacity—that is, the work the team can realistically complete in each Sprint.

Daily Scrum Meeting (Daily Standup)

The team uses this meeting to make micro-commitments to each other, identify issues, and ensure Sprint work flows smoothly within the team. It is usually 15 minutes long. The team answers the following questions:

  • What did I complete since the last Scrum meeting?
  • What is my plan for today? What do I intend to complete between now and the next Scrum meeting?
  • Are there any impediments (problems, issues, or risks) blocking me?

Remember, this meeting is not a status meeting—it is not for solving problems, but for becoming aware of problems (if any). If a meeting is needed to resolve issues, hold one separately.

Sprint Review Meeting

At the end of each Sprint, the team demonstrates all completed work items. This review meeting is used to receive feedback from project stakeholders and any change requests.

It is important to note that work items not 100% complete according to the Definition of Done established during planning will not be demonstrated, as they are not “Done.”

Sprint Retrospective Meeting

This takes place after the Sprint Review. The purpose is to help the team learn from the Sprint. The process focuses on continuous improvement rather than blaming the team if things did not go well during the Sprint.

The team reflects on how to become more effective and identifies other areas for improvement.

The Scrum Master ranks the importance of each improvement item, and then the team selects an appropriate number of improvement items to implement in the next Sprint.