1

In this lecture, we’re going to discuss some background information about how Scrum
works. This is an optional lecture for anyone who wants a little more detail on Scrum

2
Scrum consists of three roles:

• The Product Owner is responsible for the overall success or failure of the project and is the
final decision-maker on defining and prioritizing requirements. The role is similar to a Product
Manager or Project Manager; however, it goes beyond the role of a normal project manager
because the Product Owner has decision-making authority on what the product should be.
The Product Owner is more focused on the “What” than the “How”

• The Scrum Master is more focused on the “How” and is responsible for facilitating the team,
managing the process, and removing impediments. The Scrum Master has some functions
that might be similar to a project manager in leading the team but it is more of a facilitation
role than a more directive leadership role. The Scrum Master is considered a “Servant
Leader”

• Finally the Development Team is responsible for developing the solution and is cross-
functional and self-organizing. Each member of the development team has some functions
that might be considered a very limited form of project management. Each member of the
team is responsible for planning and managing their own tasks and reporting progress and
the team, as a whole, is responsible for coordinating the work that is done by all the members
of the team

The project management functions that might normally be done by a single individual called a
“Project Manager” in a traditional plan-driven project are distributed among the three roles and
the emphasis has shifted from a focus on controlling the project to manage costs and schedules
to a focus on maximizing the business value of the solution

3
This diagram shows the major elements of a Scrum Process

The Product Backlog is a prioritized queue of features to be developed that is typically

expressed in incremental units of functionality called “User Stories”

4
The Product Backlog is continuously refined, prioritized, and clarified as the project
progresses in a process called “Product Backlog Grooming”. You can visualize this
process like an “iceberg”.

Requirements start out at the bottom of the iceberg and at that point they may be
defined at a high level without much detail.

As requirements move up to the top of the iceberg, they become more well-defined
using a “just-in-time” process so that the a sufficient number of requirements are ready
to start development prior to the beginning of each Sprint.

A general rule of thumb is that the top of the Product Backlog has sufficient
requirements ready for development for about 2-3 sprints.

5
The heart of a Scrum process is the “Sprint” – that is where the work gets done.

A Scrum project is broken up into sprints which are typically fixed length intervals of time
that are 2-4 weeks long. The work is “time-boxed”. In a traditional plan-driven project,
the length of time is expanded to fit the work to be done. In a Scrum project, the length
of the sprint is typically fixed and the work to be done is limited to the capacity of work
the team can accomplish in a single sprint

At the beginning of each Sprint, the Product Owner prioritizes the user stories to be
considered for inclusion in the sprint, and the team commits to the functionality that can
be done in the sprint based on their estimated velocity and capacitty

6
The Sprint Backlog is a subset of the overall Product Backlog and consists of the items
that the team has committed to include in the current sprint and is drawn from the
Product Backlog at the beginning of the sprint

7
During the sprint, there is a Daily Standup Meeting every day to review progress,
coordinate work in progress, and resolve any issues. These meetings are typically
limited to 15 minutes and they are typically done with all the members standing up to
encourage keeping the meetings short.

Because these meetings are done daily, any problems or issues that might impact
successful completion of the sprint are discovered quickly and resolved.

8
During the sprint, the team meets with the Product Owner and users to clarify
requirements if necessary and to demonstrate partially completed work for feedback
and inputs

9
At the end of every sprint, there is a Sprint Review to review and accept the work
completed in the Sprint which provides timely feedback from both the Product Owner
and potential stakeholders and users. The Sprint Review is similar to a User Acceptance
Test (UAT) in a full-scale, plan-driven project.

10
At the end of every sprint, there is a sprint retrospective to review what went well and
what didn’t go well in the sprint from a process perspective and improvements are made
in the process as necessary prior to the next sprint. The Sprint Retrospective at the end
of the sprint is similar to a post mortem in a full scale project

11
In the next lecture, we’re going to provide a quick overview of how a hybrid Agile
process would work.
Thanks for taking the time to do this lecture and I’ll look forward to working with you in
the rest of the course.

12