Scrum Manual

Kareem Elhiny

HOW TO SCRUM A guide for practicing Scrum effectively

HOW TO SCRUM | Kareem Elhiny

P a g e | 1

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


P a g e | 2

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

3. Scrum Adoption ..................................................................................................... 30

4. Scrum Roles & Practices ....................................................................................... 34

VIII. Citations ....................................................................................................................... 38


P a g e | 3

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.


P a g e | 4

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.


P a g e | 5

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.


P a g e | 6

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.


P a g e | 7

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.


P a g e | 8

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.


P a g e | 9

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


P a g e | 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Survey Respondent Profile

1) Where are you located?

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

3) What certifications do you have?

4%

4%

6%

10%

44%

Canada

UK

Germany

India

US

TOP 5 COUNTRIES

11%

11%

33%

44%

Other

Product Development

IT

Software Development

6%

7%

21%

59%

None

PMI only

Scrum and PMI

Scrum only


P a g e | 29

4) In what industry do you work in?

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

6) What agile approach is your organization using?

2%

3%

4%

5%

6%

7%

21%

29%

Transportation, Automotive

Manufacturing, Retail, Media, R&D

Education

Insurance

Healthcare, Consulting, Government,Telecom

Finance

Other

Information Technology

5,000 to 19,99916%

20,000 or

more21%500 to

4,99926%

1 to 49937%

Number of Employees

Under $1M7%

$1-$10M16%

$10-$50M14%

$50-$500M

19%

$500M-$1B10%

Over $1B33%

Employer's Annual Revenue

13%

21%

43%

95%

Extreme Programming (XP)

Lean

Kanban

Scrum


P a g e | 30

3. Scrum Adoption

7) How is Scrum applied in your organization?

8) Has Scrum improved your team’s quality of life?

9) Is there tension between the way Scrum teams are run and the

way the rest of your organization is managed?

2%

3%

4%

8%

11%

25%

47%

Scrum used for some non-softwareprojects

We tried Scrum but no decision was madeto go further

Other

Scrum is deployed across the organization

We are piloting Scrum

Scrum is used for all softwaredevelopment

Scrum is one of the practices we use

4%

10%

31%

56%

No

Not sure

To some extent

Yes

7%

22%

35%

36%

Not sure

No

To some extent

Yes


P a g e | 31

10) If your Scrum projects were deployed and managed through a

PMO, how effective and successful were they?

11) When your organization was adopting Scrum, which of the

following were important?

12) What is the highest business priority for Scrum project?

Succesful93%

2%

5%

7%

14%

71%

Clearly identified metrics to identify &measure success of adopting &…

Smooth and conflict free transition fromexisting practices to Scrum

Alignment of Scrum with the strategic &financial goals of the company as a whole

A clear set of business goals to be achievedwith Scrum

Active senior management sponsorship andsupport

4%

10%

16%

21%

49%

Other

Adding new features and functionality

Completing projects that driveinnovation and market share

Meeting budget, time and scopeconstraints

Fulfilling customer needs


P a g e | 32

13) Which area would you say is most valued by your organization’s

executives for delivery of Scrum-based projects?

14) How would you describe the culture of organization in terms of

facilitating Scrum?

15) Does your organization require Scrum or other project

management certification?

6%

27%

45%

51%

79%

Other

Cost

Quality

Meeting scheduled deadlines

Delivering business value to thecustomer

7%

9%

9%

21%

24%

52%

Senior management actively endorsesand supports Scrum

Our organizaiton does not endorseand/or use Scrum

The Scrum team is self-organizing

The Scrum Master has authority andability to remove impediments

The Scrum team is empowered to doits work

An open environment of cooperationand collaboration between customer,

Scrum teams and product owner exists

7%

45%

48%

Requires certification

Does not require or endorse anycertification

Recommends certification


P a g e | 33

16) Has obtaining certification improved the process and practices

of Scrum?

17) Does your organization seek training and coaching?

No Difference14%

Strongly Disagree

1%

Disagree4%

Agree58%

Strongly Agree23%

8%

21%

59%

Scrum teams are certified

Product owners arecertified

Scrum teams are certified


P a g e | 34

4. Scrum Roles & Practices

18) How would you describe the role of the Scrum Master on your

projects?

19) How would you describe the role of the Product Owner on your

projects?

16%

23%

24%

37%

There is a project manager inaddition to the Scrum Master

A traditional project manager will actin the role of Scrum Master

Each project has a dedicated ScrumMaster

Each project has a Scrum Masterwho may be assigned to multiple

projects

12%

26%

29%

33%

There is no product owner role

The product owner works directly withthe Scrum team

There is a dedicated product owner whosets priorities and works with the

customer

The product owner acts as anintermediary to consolidate and

reconcile the priorities of multiplestakeholders


P a g e | 35

20) How would you describe your Scrum team’s communications

and organization?

21) When does your team hold sprint planning meetings?

22) Does your team hold Scrum meetings daily?

6%

8%

12%

15%

26%

33%

The Scrum team is cross functional

The Scrum Master or PM drivesestimates/team communication

The Scrum team is included in workeffort estimates and ordering the

product backlog

The Scrum team is self directed and selforganizing

The Scrum team is co-located

The Scrum team is distributed acrossdifferent sites/geographic areas

5%

12%

83%

No sprint planning meetings areheld

At beginning of project

Prior to a sprint

3%

5%

11%

81%

Not done

As needed

Multiple times a week, but notdaily

Daily


P a g e | 36

23) When does your team hold retrospectives?

24) How often are Scrum artifacts, such as the product backlog and

the sprint backlog used?

25) If your organization has an existing Waterfall method in place,

what was your experience when Scrum was introduced?

10%

12%

79%

No retrospectives are held

At the end of the project

After each sprint

3%

6%

34%

56%

No formal project documentation isused

We use our own internal projectdocuments

Some are used

Used extensively and in every Scrumproject

4%

4%

9%

20%

23%

40%

Scrum or Waterfall Scrum was introducedand integrated into our Waterfall method

We were not succesful in introducingScrum, so we stayed with our Waterfall

method

After a thorough evaluation of a projectstype, requirements and parameters, a

decision is made to use either

Scrum was very succesful and that is allwe use now

Scrum was succesfully introduced inaddition to our Waterfall method

Scrum was used for some projects andWaterfall for the rest


P a g e | 37

26) What were some of the challenges faced by your organization in

achieving its goals with Scrum?

27) Considering all the projects your organization that were

managed using Scrum, what percent of the time would you

estimate they were delivered successfully?

7%

23%

35%

41%

46%

52%

Other

We did not get senior managementsupport

Product owners and teams were justnot willing and or enthusiastic about

Scrum best practices

Alignment with other projects in theportfolio

It was difficult to transition from aWaterfall based method to one driven

by Scrum practices

We did not have clearly identifiedmetrics to identify and measure success

of Scrum projects and delivery

12%

14%

32%

42%

0-25% of time

25-50% of time

50-75% of time

75%+ of time

50%

65%

77%

3 or fewer on Scrum team

10 or more on Scrum team

4-9 on Scrum team

AMOUNT OF TIME SCRUM IS SUCCESSFUL BY TEAM SIZE


P a g e | 38

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

i

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/

http://www.scrumalliance.org/

http://www.scruminc.com/

Scrum Manual

Documents

Transcript of Scrum Manual