Scrum Manual

HOW TO SCRUM
A guide for practicing Scrum effectively
Kareem Elhiny
HOW TO SCRUM | Kareem Elhiny
Table of Contents
I. Overview of Agile & Scrum ......................................................................................... 3

A. Purpose & Structure of the Guide ............................................................................... 3
B. What is Agile? ............................................................................................................. 3
C. What is Scrum? ........................................................................................................... 4
II. Glossary of Terms ......................................................................................................... 5
III. Scrum Foundations ....................................................................................................... 8
A. Scrum Pillars ............................................................................................................... 8
B. Scrum Values .............................................................................................................. 8
C. Other Concepts ............................................................................................................ 9
D. Engineering Best Practices ........................................................................................ 10
IV. Scrum Roles ................................................................................................................. 11
A. Product Owner........................................................................................................... 11
B. Scrum Master ............................................................................................................ 11
C. Development Team ................................................................................................... 12
D. Non-Core Parties ....................................................................................................... 13
V. Scrum Artifacts ........................................................................................................... 14
A. Product Backlog ........................................................................................................ 14
B. Sprint Backlog ........................................................................................................... 15
C. Product Increment ..................................................................................................... 16
D. Artifact Transparency................................................................................................ 16
VI. Scrum Process ............................................................................................................. 17
A. Scrum Events............................................................................................................. 17
B. Scrum Product Development Process ....................................................................... 18
1. Overview ............................................................................................................... 18
2. Initiate .................................................................................................................... 19
3. Plan ........................................................................................................................ 20
4. Implement .............................................................................................................. 22
5. Review ................................................................................................................... 23
VII. State of Scrum ............................................................................................................. 26
1. Main Findings ........................................................................................................ 26
Page |1
2. Survey Respondent Profile .................................................................................... 28

3. Scrum Adoption ..................................................................................................... 30
4. Scrum Roles & Practices ....................................................................................... 34
VIII. Citations ....................................................................................................................... 38
Page |2
I. Overview of Agile & Scrum

A. Purpose & Structure of the Guide
Since its conception in the early 90’s, the Scrum process has exploded in popularity. Today,
Scrum is used throughout the world by companies of varying industries and sizes. Companies
are reporting an average success rate of 62%i for Scrum managed projects, roughly 11% higher
than the reported success rate of Waterfall managed projectsii. Not surprisingly, 95% of
organizations using Scrum consider it likely that they will continue to use it in the futureiii.
For aspiring Scrum users, there is a wealth of free material to understand Scrum. The Scrum
Guide is an essential resourceiv. Scrumtrainingseries.com created a series of user-friendly
tutorial videosv while websites such as scrumalliance.com or mountaingoatsoftware.com
contain countless articles written by experienced Scrum practitioners. This guide brings
together information and insights from many of Scrum’s leading voices into one place.
After explaining Agile and Scrum, important terms are defined and the foundations of Scrum
are presented. Next, a description is provided of the various roles, artifacts and events which
keep the process ticking. Later, the agile product development process is described in some
detail. Where possible, we distinguish between the core Scrum guidance and the non-core,
supplemental guidance. Finally, key insights are provided from the State of Scrum Report,
produced by Scrum Alliance®, which surveyed almost 5,000 people about their use of Scrum.
B. What is Agile?
Agile is a philosophy and set of methodologies used for product development which is more
lightweight and flexible than the traditional Waterfall Approach. The Agile philosophy is based
on iterative development where requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams. Agile processes allow for rapid delivery of
high quality software and are guided by the following concepts:
 Frequent inspection and adaptation.

 Encouraging teamwork, self-organization and accountability.
 Application of software engineering best practices.
 A business approach that aligns development with customer needs and company goals.
Examples of Agile approach include (but are not limited to): Scrum, Kanban, Lean, Extreme
Programming. Examples of Agile practices include (but are not limited to): Pair Programming,
Test Driven Development, Refactoring, Time-boxing, User Storying.
The Agile manifesto has 4 core principles and 12 guiding principles. It can be found at
www.agilemanifesto.com.
Page |3
C. What is Scrum?
Scrum is a subset of Agile; it is a framework for developing complex and adaptive products
of the highest possible business value. It is a cyclical process that aims to release a potentially
shippable product at the end of each cycle (also called a Sprint).
Scrum derives from the theory of empiricism; which asserts that knowledge comes from
experience and making decisions based on what is known.
Scrum framework can be captured in three main branches: Scrum Roles, Scrum Events,
and Scrum Artifacts. Scrum provides simple working rules to optimize team effectiveness.
Scrum emphasizes the importance of self-managing, self-regulating teams;
Scrum delivers several key benefits including: Delivering high value increments more
quickly, coping better with change and uncertainty, providing better estimates and spending
less time creating them, controlling project schedule and status more effectively.
Scrum is simple but Scrum is not easy.
Page |4
II. Glossary of Terms

Acceptance Criteria: Pre-established criteria or requirements that are unique for each User
Story and that a User Story must meet to be considered Done.
Agile: A philosophy and set of methodologies used to develop products which is more
lightweight and flexible than the traditional waterfall approach.
Burndown Chart: Shows the planned versus actual progress as measured in Story Points.
Burndown Chart is a common mechanism to monitor progress during a single Sprint or over
multiple Sprints.
Customers: Individuals or businesses who are users of the product.
Daily Scrum: The prescribed Scrum Event where the Development Team synchronizes its
activities and creates a plan for the next 24 hours.
Definition of Done: Pre-established criteria, that applies to all User Stories, that a User Story
must meet to be considered Done.
Developer: A member of the Development Team.
Development Team: A self-organizing team that is responsible and accountable for delivering
potentially shippable Product Increments at the end of each Sprint.
Done: When a User Story which has met both the Definition of Done and the Acceptance
Criteria.
Epic: A high level description or functionality of the product which broadly defines its
requirements. Epics are effectively unrefined User Stories in the Product Backlog.
Internal Stakeholder: Relevant employees or managers who have a stake in the outcome of
the product development process.
Planning Poker: A commonly used technique or method for estimating effort required to
complete User Stories as measured by Story Points.
Product Backlog: An ordered list of everything that might be needed in the product and is the
single source of requirements for any changes to be made to the product.
Product Backlog Item (PBI): An Epic or User Story in the Product Backlog; Has the attributes
of a description, order, estimate and value.
Product Backlog Refinement: The act of adding detail, estimates and order to items in the
Product Backlog.
Page |5
Product Increment: The sum of all Product Backlog Items completed during a Sprint plus the
sum of the Increment resulting from previous Sprints.
Product Owner: Individual who is responsible for maximizing the business value of the
product.
Project Vision Statement: A brief statement which verbalizes the business rationale and
intended or desired outcomes of the project.
Release Plan: An estimate of the product’s Release Date(s).
Scrum: A framework for developing complex and adaptive products.
Scrum Artifacts: Information radiators for the Scrum Team that provide information about
the product under development, including completed and planned activities.
Scrum Board: A white board that is used to make the Sprint Backlog visible to everyone. The
Scrum Board is kept up to date to show the progress of User Stories and Tasks as they move
through each stage from “To Do” to “Done”.
Scrum Events: Prescribed events which must take place during every Sprint. The four Scrum
Events are; Sprint Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective.
Scrum Master: Individual who is responsible for ensuring Scrum is understood and enacted.
Scrum Pillars: The three guiding principles of Scrum; Transparency, Inspection and
Adaptation.
Scrum Roles: Scrum prescribes three roles with unique responsibilities; Product Owner,
Scrum Master and Developer.
Scrum Team: The Scrum Team is composed of the Product Owner, Scrum Master and
Development Team.
Scrum Values: The five values which Scrum Teams should embody; Commitment, Courage,
Focus, Openness, Respect.
Sprint: A cycle with a pre-determined length during which a Scrum Team aims to create a
potentially shippable Product Increment.
Sprint Backlog: The set of Product Backlog Item’s selected for the Sprint. It is the forecast
about what functionality will be in the next Product Increment and the work needed to deliver
that functionality into a Done Increment.
Sprint Goal: A short description of the desired outcome of the upcoming Sprint.
Sprint Planning: The process of preparing for the upcoming Sprint during the Sprint Planning
meeting.
Page |6
Sprint Planning Meeting: The prescribed Scrum Event where the Scrum Team prepares for
the upcoming Sprint.
Sprint Retrospective: The prescribed Scrum Event where the Development Team inspects
itself and creates a plan for future improvements.
Sprint Review: The prescribed Scrum Event where the Increment is presented to Stakeholders
and feedback is received by the Scrum Team.
Stakeholders: Stakeholders include both Customers and Internal Stakeholders who have a
stake in the outcome of the product development process.
Story Points: A unit of measurement used for estimating the effort of User Stories and
measuring Velocity of the Development Team.
Tasks: Tasks are specific activities required to complete a User Story.
User Story: Short, simple descriptions of a feature told from the perspective of the end user.
They should be clear, feasible and testable and fit comfortably into a Sprint.
Velocity: The sum of the estimates of User Stories completed during a Sprint and measured in
Story Points.
Waterfall Approach: The traditional approach to software development which followed a

linear sequential life cycle model, i.e: each phase must be completed before the next phase can
begin and there is no overlapping in the phases.
Page |7
III. Scrum Foundations

A. Scrum Pillars
The framework is governed by three guiding principles:
1) Transparency: Transparency means that Scrum Team members share and have access
to common information to promote better communication and decision-making
(technical decisions, planning or task distribution decisions, process decisions, etc.)
2) Inspection: Scrum Teams must frequently inspect Scrum Artifacts to identify

challenges and impediments to completing their work. The team inspects its own work
using tools like the Scrum Board and Burndown Chart, and by collecting feedback from
Customers and other Stakeholders.
3) Adaptation: After learning through Transparency and Inspection, the Scrum Team
adapts by making improvements in the work they are doing. Scrum Teams can adapt
features to the products they are developing or their ways of working with one another.
B. Scrum Values
In addition to the guiding principles, Scrum also highlights five core values:
1) Commitment: Teams commit to what they will complete during each Sprint and to
how the work will be done.
2) Courage: Having the support and resources of a team provides the courage to undertake
greater challenges.
3) Focus: Focus on a few things at a time allows for better quality work and delivery of
valuable items sooner.
4) Openness: The Scrum Team and its stakeholders agree to be open about all the work
and the challenges with performing the work.
5) Respect: Scrum Team members respect each other to be capable, independent people.
Page |8
C. Other Concepts
In addition to the above principles and values, there are a few other Agile concepts which are
not explicitly associated with Scrum but are worth mentioning:
1) Iterative development: Iterative development promotes frequent, incremental releases

which has at least two benefits compared to the traditional approach: a) feedback is
provided continually by Stakeholders, not only after the final release, and is quickly
incorporated by the Scrum Team; b) value is created and captured incrementally; and
not only after the final release.
2) Value based prioritization: In Scrum, the Product Owner works with Customers or
Internal Stakeholders to understand the value of different business requirements, and
works with the Scrum Team to identify risks and dependencies between requirements.
These inputs are used to create a prioritized Product Backlog which delivers the highest
business value in the least amount of time.
3) Self-organization: Scrum favors employees who are self-motivated and accept greater
responsibility, working best through self-organization. Self-organization has several
benefits: a) Team buys in and shares ownership; b) Higher motivation leads to better
team performance; c) Innovative and creative environment conducive to growth.
4) Collaboration: In Scrum, collaboration means leveraging the team’s collective

strengths and expertise. Some of the benefits of collaboration include: a) Clearer
articulation of project requirements leading to fewer changes; b) Risks are better
identified and dealt with through exchange of information; c) Team reach full potential
as members better understand each other's strengths and weaknesses; d) Continuous
improvement is ensured through sharing of lessons learned.
5) Time-boxing: Time-boxing happens by limiting sprint cycles from 1-4 weeks, and
capping Scrum Events to certain time limits. In this way, an efficient development
process is maintained that prevents excessive, unnecessary improvement of an item
(gold-plating).
Page |9
D. Engineering Best Practices

Although Scrum refrains from recommending specific engineering practices, many Scrum
teams have experienced success by pairing the framework with engineering practices from the
eXtreme Programming movement (XP). Here are 3 widely used practices, noting that each
team must decide on what works best for them:
 Pair Programming: Two developers work together at one work station. The
“navigator” focuses on the overall direction while the “driver” is actively involved
in the programming task. The two should frequently switch roles.
 Test Driven Development: TDD is where a test (that fails) is coded prior to writing
the production code (that makes the test pass).
 Continuous Integration: Integration is done at least on a daily basis and not after
completing all other tasks.
 Other Examples: Refactoring, small releases, sustainable pace.
P a g e | 10
IV. Scrum Roles

Scrum Teams consist of three main Roles: Product Owner, Scrum Master, and Development
Team. Each has specific roles and responsibilities at each stage of the Sprint; the three parties
should respect and empower each other in a way that contributes to the overall team’s
effectiveness.
A. Product Owner
The Product Owner is responsible for maximizing the business value of the project. They are
the voice of the Customer, needing to understand and articulate their requirements and the
business justification for the project.
The Product Owner is accountable for the Product Backlog. This involves: a) clearly
expressing and refining backlog items, b) prioritizing and ordering items based on perceived
business value, c) ensuring the backlog is clear and transparent to everyone d) ensuring the
backlog is well understood by the Development Team.
The Development Team may help the Product Owner with the Product Backlog but the Product
Owner remains accountable.
Anyone wanting to change a Product Backlog Item’s priority must address the Product Owner.
No one is allowed to tell the Development Team to work from a different set of requirements
and the Development Team can’t act on what anyone else says. For the Product Owner to
succeed, the entire organization must respect his or her decisions.
B. Scrum Master
The Scrum Master is a gentle facilitator who helps to create an environment which promotes
successful product development. The Scrum Master is responsible for ensuring Scrum is
understood and enacted by facilitating Scrum Events, educating on Scrum best practices and
helping the Development Team to develop its own policies and rules. He/she is also tasked
with removing organizational impediments that hinder the team.
The Scrum Master supports the Product Owner in the following ways:
● Ensuring Product Owner knows how to arrange Product Backlog to maximize value.
● Helping Scrum Team understand the need for having clear & concise Product Backlog
Items.
● Understanding product planning; Understanding and practicing agility.
P a g e | 11
The Scrum Master supports the Development Team in the following ways:
 Coaching in self-organization and cross-functionality.

 Removing impediments to their progress.
 Facilitating Scrum Events as requested or needed.
The Scrum Master supports the organization in the following ways:
 Planning, leading and coaching the organization in its Scrum adoption.

 Helping Internal Stakeholders understand Scrum and product development process.
C. Development Team
The Development Team is a self-organizing, cross functional team who is empowered by the
organization to organize and manage their own work. They must select, with the Product
Owner, which Product Backlog Items they will aim to complete during a Sprint and are
responsible and accountable for delivering a potentially shippable Product Increment at the end
of each Sprint. The team defines its own practices, policies and procedures.
The Development Team supports the Product Owner to refine the Product Backlog into smaller
pieces, to define the tasks required to complete it and to allocate the work among themselves
in an effective way.
The Development Team is responsible for inspecting and adapting itself, with the help of the
Scrum Master and using Scrum Events as a platform. Self-regulation or holding each other
accountable is an important element of the team dynamic.
Scrum recognizes no sub-teams and no titles for Development Team members other than
Developer. Even though members may have specialized skills and areas of focus,
accountability belongs to the Development Team as a whole.
Optimal team size is small enough to stay agile and well-coordinated but large enough to
complete significant work during a Sprint; Scrum recommends a range of 3-9 Developers.
P a g e | 12
D. Non-Core Parties
While Scrum only recognizes the above mentioned roles, it is worth highlighting the role of
other important Stakeholders in the process.
Customers
Customers are people, businesses or Internal Stakeholders who are users of the product.
According to Agile principles, satisfying Customers is a foremost priority. It is imperative for
the Scrum Team to be aware of and reflect Customer’s needs into the Products they develop.
As the voice of the Customer, the Product Owner is responsible for collecting initial
Customer’s requirements and to be aware of new requirements. This practice ensures that the
prioritization of Product Backlog Items is customer centric and delivers the highest business
value and helps to create meaningful User Stories.
Internal Stakeholders
Internal Stakeholders are employees or managers who have a stake in the outcome of the
development process. In some cases, Internal Stakeholders are users of the product. In other
cases, they will interact with Customers who use the product. In all cases, it is important to
involve Internal Stakeholders at specific times, typically while defining initial requirements
determination and at Sprint Reviews.
Product Owner should keep the Product Backlog visible to Internal Stakeholders and update
them during Sprint Review. Scrum Master should help Internal Stakeholders understand Scrum
theory and principles and to advise them on which practices hurt or hinder the Scrum Team.
Internal Stakeholders may not interfere directly or take decisions that affect the Scrum Team;
It is imperative that they respect the boundaries, processes and Roles defined by Scrum.
P a g e | 13
V. Scrum Artifacts
Scrum Artifacts are information radiators for the Scrum Team which are designed to provide
maximum transparency and facilitate a common understanding about the product under
development, including completed and planned activities. This section is copied nearly
verbatim from the Scrum Guide with minor additions.
A. Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the product and
is the single source of requirements for any changes to be made to the product. The Product
Owner is responsible for the Product Backlog including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development only lays out the initially
known and best-understood requirements. The Product Backlog evolves as the Product and the
environment in which it will be used evolves. The Product Backlog is dynamic; it constantly
changes to identify what the product needs to be appropriate, competitive, and useful. As long
as a product exists, its Product Backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements and fixes that
constitute the changes to be made to the product in future releases. Product Backlog Items have
the attributes of a description, order, estimate and value.
As a product is used and gains value, and the marketplace provides feedback, the Product
Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a
Product Backlog is a living artifact.
Product Backlog Refinement
Product Backlog Refinement is the act of adding detail, estimates, and order to items in the
Product Backlog. This is an ongoing process in which the Product Owner and the Development
Team collaborate on the details of Product Backlog Items. During Product Backlog
Refinement, items are reviewed and revised. The Scrum Team decides how and when
Refinement is done. However, Product Backlog Items can be updated at any time by the
Product Owner or at the Product Owner’s discretion. Refinement should consume no more than
10% Development Team’s capacity.
Monitoring Progress Toward a Goal
At any point, the total work remaining to reach a Sprint Goal can be summed. The Product
Owner tracks this total work remaining at least every Sprint Review. The Product Owner
compares this amount with work remaining at previous Sprint Reviews to assess progress
P a g e | 14
toward completing projected work by the desired time for the Goal. This information is made
transparent to all relevant Stakeholders.
Various projective practices upon trending have been used to forecast progress, like burn-
downs, burn-ups, or cumulative flows. These have proven useful. However, these do not
replace the importance of empiricism. In complex environments, what will happen is unknown.
Only what has happened may be used for forward-looking decision-making.
Definition of Done
When a Product Backlog Item or an Increment is described as “Done”, everyone must

understand what “Done” means. Although this varies significantly per Scrum Team, members
must have a shared understanding of what it means for work to be complete, to ensure
transparency. This is the definition of “Done” for the Scrum Team and is used to assess when
work is complete on the product Increment.
The same definition guides the Development Team in knowing how many Product Backlog
Items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments
of potentially shippable functionality that adhere to the Scrum Team’s current definition of
“Done.” Development Teams deliver an Increment of product functionality every Sprint. This
Increment is useable, so a Product Owner may choose to immediately release it. If the
Definition of Done for an increment is part of the conventions, standards or guidelines of the
development organization, all Scrum Teams must follow it as a minimum. If Done for an
increment is not a convention of the development organization, the Development must define
a definition of Done appropriate for the product. Each Increment is additive to all prior
Increments and thoroughly tested, ensuring that all Increments work together.
As Scrum Teams mature, it is expected that their Definitions of Done will expand to include
more stringent criteria for higher quality. Any one product or system should have a definition
of “Done” that is a standard for any work done on it.
B. Sprint Backlog
The Sprint Backlog is the set of Product Backlog Items selected for the Sprint. The Sprint
Backlog is a forecast by the Development Team about what functionality will be in the next
Increment and the work needed to deliver that functionality into a “Done” Increment.
The Sprint Backlog makes visible all the work that the Development Team identifies as
necessary to meet the Sprint Goal.
The Sprint Backlog is a plan with enough detail whereby changes in progress can be understood
in the Daily Scrum. As the Development Team works through the plan and learns more about
the work needed to achieve the Sprint Goal, the Development Team refines the Tasks
P a g e | 15
comprising the Sprint Backlog. As work is performed or completed, the estimated remaining
work is updated. When elements of the plan are deemed unnecessary, they are removed.
While adding Tasks to the Sprint Backlog Items is possible, adding items from the Product
Backlog is generally discouraged, except in exceptional circumstances. Only the Development
Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible,
real-time picture of the work that the Development Team plans to carry out during the Sprint,
and it belongs solely to the Development Team.
Monitoring Sprint Progress
At any time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The
Development Team tracks this total work remaining at least for every Daily Scrum to project
the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress.
C. Product Increment
The Increment is the sum of all the Product Backlog Items completed during a Sprint and the
value of the Increments of all previous Sprints. At the end of a Sprint, the new Increment must
be Done, which means it must be in useable condition and meet the Scrum Team’s Definition
of Done.
D. Artifact Transparency
Scrum relies on transparency. Decisions to optimize value and control risk are made based on
the perceived state of the Artifacts. To the extent that transparency is complete, these decisions
have a sound basis.
The Scrum Master must work with the Product Owner, Development Team, and other involved
parties to understand if the Artifacts are completely transparent. There are practices for coping
with incomplete transparency; the Scrum Master must help everyone apply the most
appropriate practices in the absence of complete transparency. A Scrum Master can detect
incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what
is being said, and detecting differences between expected and real results.
The Scrum Master’s job is to work with the Scrum Team and the organization to increase the
transparency of the Artifacts. This work usually involves learning, convincing, and change.
Transparency doesn’t occur overnight, but is a path.
P a g e | 16
VI. Scrum Process

A. Scrum Events
Prescribed events are used in Scrum to create regularity and to minimize the need for other
unnecessary meetings. All events are time-boxed to a maximum duration. Once a Sprint begins,
its duration is fixed and cannot be shortened or lengthened; Other events may end when their
purpose has been achieved, ensuring that an appropriate amount of time is spent without any
being wasted. Each Scrum Event is designed to facilitate transparency and inspection, which
should be followed by adaptation.
The four official Scrum Events are:
a) Sprint Planning Meeting

b) Daily Stand-Up
c) Sprint Review
d) Sprint Retrospective.
In the next section, the purpose of Scrum Events will be explained while describing the overall
product development process, under Agile principles.
P a g e | 17
B. Scrum Product Development Process
1. Overview
While Scrum only recognizes the above events, it is important to understand how these fit
within the larger product development process. In this section, we will describe all the steps in
product development process using Scrum. Projects can be grouped into four stages: 1) Initiate;
2) Plan; 3) Implement; 4) Review.
1) Initiate
This stage happens just once at the beginning of a project.
 Create Project Vision Statement

 Develop Epics
 Create prioritized Product Backlog
 Conduct Release Planning
2) Plan
This stage happens at the start of every sprint, during the time-boxed Sprint Planning.
 Define Sprint Goal

 Create User Stories
 Estimate & commit to User Stories
 Create & estimate Tasks
 Finalize Sprint Backlog
3) Implement
This stage represents the work carried out during a Sprint.
 Conduct Daily Scrum

 Refine Product Backlog
4) Review
This stage is carried out at the end of each Sprint and once at the end of the project.
 Sprint Review
 Sprint Retrospective
P a g e | 18
2. Initiate
Create Project Vision
The Project Vision Statement is not mandatory under Scrum. However, there is value in
creating a brief statement which verbalizes the business rationale and intended or desired
outcomes of the project. Naturally, conditions may change along the way that alter the project
vision. An initial kickoff meeting, led by the Product Owner, is an effective tool for capturing
different Stakeholder’s expectations and getting their commitment.
Develop Epics
Epics are high level descriptions or functionalities of the product which broadly define its
requirements. Epics are effectively unrefined User Stories in the Product Backlog which are
defined by the Product Owner. Once they come up in the Product Backlog for completion in
an upcoming Sprint, they are broken down into smaller User Stories which are simple, short
and easy to implement functionalities or blocks of tasks to be completed in a Sprint.
Create prioritized Product Backlog
The Product Owner sorts the Epics into a prioritized Product Backlog, which is one of the three
Scrum Artifacts. There are many rationales and techniques for ordering items, although
maximizing Return on Investment is a common factor in most. Some commonly used
techniques include Kano Analysis, Relative Weighting and Theme Screening.
Develop a Release Plan
The Release Plan is an estimate for the Release Dates of certain product features. It takes a
forward looking view encompassing several sprints while also serving as a benchmark to
monitor development progress. The Release Plan is developed by the Product Owner jointly
with the Development Team; the plan should stay visible to the Scrum Team and relevant
Stakeholders, which provides transparency and aligns expectations.
The first step for building the Release Plan is to determine the conditions that should be
satisfied to trigger a release (which features and functionalities should be done); Depending on
the product, it is possible to have a single release or multiple incremental releases. After
determining release conditions, Release Dates are forecasted using the Product Backlog and
the Scrum Team’s estimated Velocity. As the Product Backlog is altered and new knowledge
is gained, Release Dates may change; Therefore, to keep Stakeholders informed and manage
expectations, it is prudent to update the Release Plan periodically.
P a g e | 19
3. Plan
At the beginning of every sprint, the Scrum Team convenes in a time-boxed Sprint Planning
Meeting to prepare for the upcoming Sprint. Over 4 hours (per 2-week sprint), the team refines
broad Epics into refined User Stories, discusses and estimates their requirements, breaks them
down into tasks, and commits them to the Sprint Backlog. At times, teams may go back and
forth between the different steps.
Define Sprint Goal
The goal of any Sprint is to create a potentially shippable product increment. The specific Sprint
Goal is defined by the Product Owner and is a short description of the desired outcome of the
upcoming Sprint. The success of the team will later be assessed against the Sprint Goal. There
are several benefits to defining the Sprint Goal. First, it helps the team prioritize since the goal
may be reached even if not all User Stories are completed. Second, it helps the Product Owner
to communicate the team’s objectives to Stakeholders on a high level without too much detail.
Effective Sprint Goals might follow the SMART framework being: Specific, Measurable,
Attainable, Relevant and Time-bound. Examples of Sprint Goals:
 Implement online checkout, whereby all customers can pay using a credit card.
 Develop the website funnel for painting to allow customers to input details about their
home through our website.
Create User Stories
User stories are short, simple descriptions of a feature told from the perspective of the end user.
User Stories should be clear, feasible and testable, and should fit comfortably into a Sprint.
They are typically written on index cards or sticky notes and follow a simple template:
As a <user>, I want <what>, so that <why>.
While it is the Product Owner’s responsibility to make sure that the backlog consists of User
Stories, the Development Team is jointly responsible for writing User Stories. Moreover,
anyone outside the team can add a User Story to the Product Backlog, but only the Product
Owner can change the order of the Product Backlog.
Of greater importance than writing the User Story is discussing it among the Scrum Team to
refine and align their understanding of its requirements and agree on a set of Acceptance
Criteria. Now is a good time to remember the principles of customer centricity and business
value.
Here is an example of how a large Epic becomes smaller User Stories:
 Epic: As a user, I want to back up my entire hard drive.

o User Story: As a user, I want to choose not to backup all folders, so that my
hard drive is not filled with files I don’t need.
P a g e | 20
o User Story: As a user, I can select files to backup based on date created so that
I can select only relevant files.
o Etc...
Estimate & Commit to User Stories
Once we have a set of User Stories that we can work with, it is time to estimate the effort
required for each.
The Scrum Team should use any method of estimation that it is comfortable with. One of the
most commonly used methods of estimation in Scrum is Planning Poker. This technique relies
on group consensus and relative estimation using Story Points rather than hours; Relative
estimation has been shown to be more accurate and done more quickly than absolute
estimation. Many teams estimate using the Fibonacci numbers: 1, 2, 3, 5, 8, 13.
The process begins with the Development Team agreeing on the effort to complete a small
activity; for example, the team might estimate 2 Story Points needed to complete X. This
becomes the first reference point and the next estimate is made relative to this. If we expect Z
to be twice the effort of X, it may be assigned either 3 or 5 Story Points.
After agreeing on a reference point, individual User Stories are estimated. After discussing a
story, each member will mentally formulate an estimate. Then everyone holds up a card with
the number that reflects their estimate. If there is a high level of agreement, then great! If there
are discrepancies (several people disagree or major outliers exist) then take some time (but not
too much time) to discuss the rationale behind different estimates. Repeat this process until
there is a high level of agreement. This process helps to align team member’s understandings
and provides guidance for how many User Stories to commit to the Sprint.
Remember, though, that estimation is not an exact science and estimates need not be perfect;
With time and inspection, the Scrum Team will become better and better at doing it!
After estimation, the Development Team selects a set of User Stories that they believe they can
complete in the upcoming Sprint, based on the team’s previous Velocity. Velocity, which is
measured in Story Points, is the sum of the estimates of User Stories completed during a Sprint.
For example, if the team completed 3 User Stories which were estimated at 10, 20, 25 Story
Points respectively, then its velocity is 10+20+25=55 Story Points. This means that the team
should include User Stories equaling roughly 55 Story Points in the upcoming Sprint. As teams
begin to use Scrum, is not unusual for Velocity to vary in early Sprint’s, although the team
should reach a stable Velocity after a few iterations.
P a g e | 21
Create & Estimate Tasks
The second half of the Sprint Planning Meeting is dedicated to breaking down User Stories into
smaller Tasks. Tasks include programming, coding, design, testing, analysis, etc.
It is common for Development Team’s to use a Scrum Board and sticky notes to make note of
all the tasks required to complete the committed User Stories. Typically, experienced teams
identify 60% of Tasks initially while other Tasks emerge during the Sprint.
Some teams also estimate the time to complete Tasks. However, unlike User Stories which are
estimated in Story Points, Tasks are typically estimated in hours. If a team feels that it has
committed to more Tasks than its capacity, the team may choose to reduce the number of User
Stories committed to the Sprint.
Ideally, Task estimates should be no longer than 1 day. If an estimate is much larger than this,
the requirements should be broken down further so the Tasks are smaller. Breaking Tasks down
means they are easier to estimate which improves accuracy. Secondly, Tasks less than 1 day
long are more measurable in the Daily Scrum Meeting.
The process of Task estimation helps anticipate the work ahead and provides a benchmark to
measure progress.
Finalize Sprint Backlog
Congratulations! With all this planning work complete, it is time to finalize the Sprint Backlog
and begin the Sprint. The Sprint Backlog should be highly visible and there are various tools
for doing so, both digitally and physically. Digitally, there are many software available which
are effective; while whiteboards are commonly used as well.
4. Implement
Once the Sprint begins, it is neither lengthened nor shortened. Although User Stories can be
added to the Product Backlog at any time, none should be added to the Sprint Backlog during
the Sprint. This rule does have exceptions, although any changes must be approved by the
Product Owner. This section is copied almost verbatim from the Scrum Guide.
Conduct Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize
activities and create a plan for the next 24 hours. This is done by inspecting the work since the
last Daily Scrum and forecasting the work that could be done before the next one. The Daily
Scrum is held at the same time and place each day to reduce complexity. During the meeting,
the Development Team members explain:
 What did I do yesterday that helped the Development Team meet the Sprint Goal?
 What will I do today to help the Development Team meet the Sprint Goal?
P a g e | 22
 Do I see any impediment that prevents me or the Development Team from meeting the
Sprint Goal?
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal.
Every day, the Development Team should understand how it intends to work together as a self-
organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end
of the Sprint. The Development Team often meet immediately after the Daily Scrum for
detailed discussions, or to adapt or re-plan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development
Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the
Development Team to keep the Daily Scrum within the 15-minute time-box. The Scrum Master
enforces the rule that only Development Team members take part in the Daily Scrum.
Daily Scrums improve communications, eliminate other meetings, identify impediments to

development for removal, highlight and promote quick decision-making, and improve the
Development Team’s level of knowledge.
Refine Product Backlog
Scrum suggests that 10% of Scrum Team capacity be dedicated to Product Backlog
Refinement. Product Backlog Items can be updated at any time by the Product Owner or at
his/her discretion, but it is common practice to conduct a Product Backlog Refinement Meeting
towards the end of a Sprint.
The purpose of Product Backlog Refinement is to decompose larger Product Backlog Items
into smaller ones and to add detail, estimates and order to Product Backlog Items near the top
of the Backlog (upcoming in the next one or two Sprints). Requirements are analyzed, new
Product Backlog Items may be added and old Product Backlog Items may be modified and re-
estimated.
While these activities are partly undertaken during Sprint Planning, it is important that Scrum
Teams come into the Sprint Planning with a good understanding and estimate of the
requirements of the upcoming Sprint. Refining Product Backlog Items make them “Ready” for
selection in a Sprint Planning, allowing the team to have more time for detailed discussion,
defining and estimating tasks during the Sprint Planning.
5. Review
At the end of every Sprint, the team inspects and adapts through two Scrum Events, the Sprint
Review and Sprint Retrospective. This section is copied almost verbatim from the Scrum
Guide.
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product
Backlog if needed. The meeting is attended by the Scrum Team and relevant Stakeholders
P a g e | 23
invited by the Product Owner. This is an informal meeting, not a status meeting, and the
presentation of the Increment is intended to elicit feedback and foster collaboration.
This is a two-hour time-boxed meeting per two-week Sprint. The Scrum Master teaches all to
keep it within the time-box, ensures that the event takes place, and that attendants understand
its purpose.
The Sprint Review includes the following elements:
 The Product Owner explains which Product Backlog Items have been “Done” and
which have not been “Done”.
 The Development Team discusses what went well during the Sprint, what problems it
ran into, and how those problems were solved.
 The Development Team demonstrates the work that it has “Done” and answers
questions about the Increment.
 The Product Owner discusses the Product Backlog as it stands. He or she projects likely
completion dates based on progress to date (if needed).
 The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning.
 Review of how the marketplace or potential use of the product might have changed and
what is the most valuable thing to do next.
The result of the Sprint Review is a revised Product Backlog that defines the probable Sprint
Backlog for the upcoming Sprint. The Product Backlog may also be adjusted or reordered to
meet new opportunities.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a
plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning
Meeting. This is a 11/2 hour time-boxed meeting per two-week Sprint. The Scrum Master
teaches all to keep it within the time-box, ensures that the event takes place, and that attendants
understand its purpose. The Scrum Master participates as a peer team member in the meeting
from the accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
 Inspect how the last Sprint went with regards to people, relationships, process, and
tools;
 Identify and order the major items that went well and potential improvements; and,
 Create a plan for implementing improvements to the way the Scrum Team does its
work.
P a g e | 24
The Scrum Master encourages the Scrum Team to improve its development process and
practices to make it more effective and enjoyable for the next Sprint. During each Sprint
Retrospective, the Scrum Team plans ways to increase product quality by adapting the
definition of “Done” as appropriate.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements
that it will implement in the next Sprint. Although improvements may be implemented at any
time, the Sprint Retrospective provides a formal opportunity to fully focus on inspection and
adaptation.
P a g e | 25
VII. State of Scrum

In February 2015, Scrum Alliance® surveyed almost 5,000 people about their use of Scrum.
The survey respondents came from 108 countries and over 14 industries, reflecting a range of
functional areas. This section provides a restatement of the main conclusions provided by
Scrum Alliance followed by most of the survey results.
1. Main Findings
a) Who is practicing Scrum?
 Scrum crosses industries, functional areas and regions around the world.
 Scrum practices are in place among 82% of respondents and another 11% are
piloting it.
 IT and software development professionals are the primary users of Scrum,
followed by product development and operations professionals.
b) Why are they practicing Scrum?
 Nearly half the respondents cite fulfilling customer needs as the highest business
priority for Scrum projects.
 The second highest priority all about meeting budget, time and scope constraints.
 87% agree that Scrum is improving the quality of work life for their teams.
 71% believe that using Scrum causes tension with 61other parts of the organization
not using Scrum.
c) How are they practicing Scrum?
 Most respondents adhere to core Scrum recommendations for practicing Scrum in

terms of using Artifacts, activities & recommended team size.
 Average team size is 7 people.
 Most Scrum teams follow 2-week Sprints
 81% hold a daily scrum
 83% conduct Sprint Planning prior to each Sprint.
 81% hold Sprint Retrospective meetings.
 90% use at least some Scrum Artifacts, while 56% use Artifacts extensively.
 Many organizations mix and match approaches and frameworks.
P a g e | 26
d) Is Scrum working?
 The overall success rate of projects delivered using Scrum is 62%.

 Teams of the recommended size, 4 to 9 people, report the most frequent success.
 The most common challenge for respondents, at 52%, is identifying and measuring
the success of Scrum projects.
 The second most common challenge, at 46%, is transitioning from a Waterfall
based method to Scrum practices.
e) Role of Certification
 81% of respondents believe certification has helped their Scrum practice.

 Nearly half of respondents’ organizations recommend certification, though only
7% require it.
 59% of Scrum Masters are certified.
f) Variables that Impact Scrum
Organizational size increases some key measures:
 Sprints get longer, averaging 2.7 weeks for teams of 10+ people.
 The top challenge shifts from measuring Scrum success to transitioning from
Waterfall to Scrum.
Geographic region matters:
 Respondents from North America and Asia report using Scrum most often.
High-level support is critical:
 Senior management sponsorship and support is far and away the most important
factor in adopting Scrum.
 Scrum projects run through a project management office have a 93% success rate.
g) The Future of Scrum
 95% of respondents say they plan to continue using Scrum moving forward.
P a g e | 27
2. Survey Respondent Profile
1) Where are you located?
TOP 5 COUNTRIES
US 44%
India 10%
Germany 6%
UK 4%
Canada 4%
2) Which area of your organization do you work in?
Software Development 44%

IT 33%
Product Development 11%
Other 11%
3) What certifications do you have?
Scrum only 59%

Scrum and PMI 21%
PMI only 7%
None 6%
P a g e | 28
4) In what industry do you work in?
Information Technology 29%

Other 21%
Finance 7%
Healthcare, Consulting, Government,
Telecom 6%
Insurance 5%
Education 4%
Manufacturing, Retail, Media, R&D 3%
Transportation, Automotive 2%
5) What is the size of your company? (Employees, Revenue)
Number of Employees Employer's Annual Revenue

Under
5,000 to $1M
7%
1 to 19,999 Over
499 16% $1B $1-$10M
37% 33% 16%
20,000
or
more $10-$50M
14%
500 to 21% $500M-
$1B $50-
4,999 $500M
10%
26% 19%
6) What agile approach is your organization using?
Scrum 95%
Kanban 43%
Lean 21%
Extreme Programming (XP) 13%
P a g e | 29
3. Scrum Adoption
7) How is Scrum applied in your organization?
Scrum is one of the practices we use 47%

Scrum is used for all software
development 25%
We are piloting Scrum 11%
Scrum is deployed across the organization 8%
Other 4%
We tried Scrum but no decision was made
to go further 3%
Scrum used for some non-software
projects 2%
8) Has Scrum improved your team’s quality of life?
Yes 56%
To some extent 31%
Not sure 10%
No 4%
9) Is there tension between the way Scrum teams are run and the
way the rest of your organization is managed?
Yes 36%
To some extent 35%
No 22%
Not sure 7%
P a g e | 30
10) If your Scrum projects were deployed and managed through a

PMO, how effective and successful were they?
Succesful
93%
11) When your organization was adopting Scrum, which of the

following were important?
Active senior management sponsorship and 71%

support
A clear set of business goals to be achieved 14%
with Scrum
Alignment of Scrum with the strategic & 7%
financial goals of the company as a whole
Smooth and conflict free transition from 5%
existing practices to Scrum
Clearly identified metrics to identify & 2%
measure success of adopting &…
12) What is the highest business priority for Scrum project?
Fulfilling customer needs 49%
Meeting budget, time and scope 21%

constraints
Completing projects that drive 16%
innovation and market share
Adding new features and functionality 10%
Other 4%
P a g e | 31
13) Which area would you say is most valued by your organization’s
executives for delivery of Scrum-based projects?
Delivering business value to the

customer
79%
Meeting scheduled deadlines 51%
Quality 45%
Cost 27%
Other 6%
14) How would you describe the culture of organization in terms of

facilitating Scrum?
An open environment of cooperation

and collaboration between customer, 52%
Scrum teams and product owner exists
The Scrum team is empowered to do
its work
24%
The Scrum Master has authority and

ability to remove impediments
21%
The Scrum team is self-organizing 9%
Our organizaiton does not endorse

and/or use Scrum
9%
Senior management actively endorses

and supports Scrum
7%
15) Does your organization require Scrum or other project

management certification?
Recommends certification 48%

Does not require or endorse any
45%
certification
Requires certification 7%
P a g e | 32
16) Has obtaining certification improved the process and practices

of Scrum?
Strongly
Disagree
No 1%
Strongly Differ
Agree ence Disagree
23% 14% 4%
Agree
58%
17) Does your organization seek training and coaching?
Scrum teams are certified 59%
Product owners are

21%
certified
Scrum teams are certified 8%
P a g e | 33
4. Scrum Roles & Practices
18) How would you describe the role of the Scrum Master on your
projects?
Each project has a Scrum Master

who may be assigned to multiple 37%
projects
Each project has a dedicated Scrum
24%
Master
A traditional project manager will act

23%
in the role of Scrum Master
There is a project manager in

16%
addition to the Scrum Master
19) How would you describe the role of the Product Owner on your
projects?
The product owner acts as an

intermediary to consolidate and
reconcile the priorities of multiple
33%
stakeholders
There is a dedicated product owner who
sets priorities and works with the 29%
customer
The product owner works directly with

the Scrum team
26%
There is no product owner role 12%
P a g e | 34
20) How would you describe your Scrum team’s communications

and organization?
The Scrum team is distributed across

different sites/geographic areas
33%
The Scrum team is co-located 26%
The Scrum team is self directed and self

organizing
15%
The Scrum team is included in work

effort estimates and ordering the 12%
product backlog
The Scrum Master or PM drives
estimates/team communication
8%
The Scrum team is cross functional 6%
21) When does your team hold sprint planning meetings?
Prior to a sprint 83%
At beginning of project 12%
No sprint planning meetings are

5%
held
22) Does your team hold Scrum meetings daily?
Daily 81%
Multiple times a week, but not
11%
daily
As needed 5%
Not done 3%
P a g e | 35
23) When does your team hold retrospectives?
After each sprint 79%
At the end of the project 12%
No retrospectives are held 10%
24) How often are Scrum artifacts, such as the product backlog and
the sprint backlog used?
Used extensively and in every Scrum

56%
project
Some are used 34%
We use our own internal project

6%
documents
No formal project documentation is
3%
used
25) If your organization has an existing Waterfall method in place,

what was your experience when Scrum was introduced?
Scrum was used for some projects and

Waterfall for the rest
40%
Scrum was succesfully introduced in

addition to our Waterfall method
23%
Scrum was very succesful and that is all

we use now
20%
After a thorough evaluation of a projects

type, requirements and parameters, a 9%
decision is made to use either
We were not succesful in introducing
Scrum, so we stayed with our Waterfall 4%
method
Scrum or Waterfall Scrum was introduced
and integrated into our Waterfall method
4%
P a g e | 36
26) What were some of the challenges faced by your organization in

achieving its goals with Scrum?
We did not have clearly identified

metrics to identify and measure success 52%
of Scrum projects and delivery
It was difficult to transition from a
Waterfall based method to one driven 46%
by Scrum practices
Alignment with other projects in the
portfolio
41%
Product owners and teams were just

not willing and or enthusiastic about 35%
Scrum best practices
We did not get senior management
support
23%
Other 7%
27) Considering all the projects your organization that were

managed using Scrum, what percent of the time would you
estimate they were delivered successfully?
75%+ of time 42%
50-75% of time 32%
25-50% of time 14%
0-25% of time 12%
AMOUNT OF TIME SCRUM IS SUCCESSFUL BY TEAM SIZE
4-9 on Scrum team 77%
10 or more on Scrum team 65%
3 or fewer on Scrum team 50%
P a g e | 37
VIII. Citations
www.scrumguides.org
www.scrumalliance.org
www.scruminc.com
www.mountaingoatsoftware.com
www.scrum.org
www.cpprime.com
www.innolution.com
www.scrumtrainingseries.com
https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/sc
rum-alliance-state-of-scrum-2015.pdf
ii
https://www.scruminc.com/
iii
https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/sc
rum-alliance-state-of-scrum-2015.pdf
iv
http://www.scrumguides.org/scrum-guide.html
v
http://scrumtrainingseries.com/
P a g e | 38

Scrum Manual

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Scrum Manual

Încărcat de

Drepturi de autor:

Formate disponibile

HOW TO SCRUM

A guide for practicing Scrum effectively

I. Overview of Agile & Scrum ......................................................................................... 3

2. Survey Respondent Profile .................................................................................... 28

I. Overview of Agile & Scrum

 Frequent inspection and adaptation.

Scrum emphasizes the importance of self-managing, self-regulating teams;

Scrum is simple but Scrum is not easy.

II. Glossary of Terms

Customers: Individuals or businesses who are users of the product.

Developer: A member of the Development Team.

Release Plan: An estimate of the product’s Release Date(s).

Scrum: A framework for developing complex and adaptive products.

Tasks: Tasks are specific activities required to complete a User Story.

Waterfall Approach: The traditional approach to software development which followed a

III. Scrum Foundations

2) Inspection: Scrum Teams must frequently inspect Scrum Artifacts to identify

1) Iterative development: Iterative development promotes frequent, incremental releases

4) Collaboration: In Scrum, collaboration means leveraging the team’s collective

D. Engineering Best Practices

IV. Scrum Roles

 Coaching in self-organization and cross-functionality.

The Scrum Master supports the organization in the following ways:

 Planning, leading and coaching the organization in its Scrum adoption.

Product Backlog Refinement

Monitoring Progress Toward a Goal

When a Product Backlog Item or an Increment is described as “Done”, everyone must

Monitoring Sprint Progress

VI. Scrum Process

The four official Scrum Events are:

a) Sprint Planning Meeting

B. Scrum Product Development Process

This stage happens just once at the beginning of a project.

 Create Project Vision Statement

 Define Sprint Goal

This stage represents the work carried out during a Sprint.

 Conduct Daily Scrum

 Epic: As a user, I want to back up my entire hard drive.

Create & Estimate Tasks

Daily Scrums improve communications, eliminate other meetings, identify impediments to

VII. State of Scrum

a) Who is practicing Scrum?

b) Why are they practicing Scrum?

c) How are they practicing Scrum?

 Most respondents adhere to core Scrum recommendations for practicing Scrum in

 The overall success rate of projects delivered using Scrum is 62%.

 81% of respondents believe certification has helped their Scrum practice.

f) Variables that Impact Scrum

Organizational size increases some key measures:

Geographic region matters:

High-level support is critical:

g) The Future of Scrum

2. Survey Respondent Profile

1) Where are you located?

2) Which area of your organization do you work in?

Software Development 44%

3) What certifications do you have?

Scrum only 59%

4) In what industry do you work in?

Information Technology 29%

5) What is the size of your company? (Employees, Revenue)

Number of Employees Employer's Annual Revenue

6) What agile approach is your organization using?

Extreme Programming (XP) 13%