Scrum@Perficient · Scrum@Perficient Scrum@Perficient A quick guide for anyone involved in a Scrum...

A MANAGEMENT CONSULTING DOCUMENT MARCH 2013

Scrum@PerficientScrum@PerficientScrum@PerficientScrum@Perficient

Copyright © 2007-2013 Perficient, Inc. All rights reserved. This material is or contains Proprietary Informa#on, Confiden#al Informa#on and/or Trade Secrets of Perficient, Inc. Disclosure to third par#es and or any

person not authorized by Perficient, Inc. is prohibited. Use may be subject to applicable non-disclosure agreements. Any distribu#on or use of this material in whole or in part without the prior wri-en approval of

Perficient, Inc. is prohibited and will be subject to legal ac#on.

A quick guide for anyone involved in a Scrum project at Perficient

Sean Scott

Scrum@PerficientScrum@PerficientScrum@PerficientScrum@Perficient

A quick guide for anyone involved in a Scrum project at Perficient

Sean Scott

Scrum (n): A framework within which people can address

complex adap#ve problems, while produc#vely and crea#vely

delivering products of the highest possible value.

The Scrum Guide—The Defini#ve Guide to Scrum: The Rules of the Game

Ken Schwaber and Jeff Sutherland

Scrum (n): a Rugby play in which, typically, three mem-

bers of each team line up opposite one another with a group

of two and a group of three players behind them, making an

eight-person, three-two-three forma#on on each side; the

ball is then rolled between the opposing front lines, the play-

ers of which stand with arms around a teammate's waist,

mee#ng the opponent shoulder to shoulder, and a-empt to

kick the ball backward to a teammate.

h-p://dic#onary.reference.com/browse/scrum

A Li-le History ·································································································· 1

An Overview of Scrum ······················································································ 2

The Pillars of Scrum ·························································································· 4

The Roles in Scrum ··························································································· 5

Scrum Events ···································································································· 8

Bibliography ··································································································· 11

Scrum—12 steps to success (figure) ······························································· 12

Glossary ········································································································· 13

Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 1

A Li�le HistoryA Li�le History

WaterfallWaterfall

In 1970 the IEEE magazine, Proceedings, published an ar#cle by Dr. Winston W. Royce #tled, “Managing

the Development of Large SoJware Systems.” In this ar#cle, Dr. Royce introduced the world to the concept

of the waterfall soJware development process. On the second page of the ar#cle a diagram shows the, now

familiar, progressive, stepwise development process.

Over forty years later, most development projects are structured using this same methodology.

Unfortunately, most people working on IT Projects don’t seem to understand the risks inherent in the

Waterfall process; nor have we embraced Dr. Royce’s recommenda#ons for mi#ga#ng these risks. The

paragraph immediately following the Waterfall diagram states:

I believe in this concept, but the implementa�on described above is risky and invites failure. The problem is

illustrated in Figure 4. The tes�ng phase which occurs at the end of the development cycle is the first event for

which �ming, storage, input/output transfers, etc., are experienced as dis�nguished from analyzed. These

phenomena are not precisely analyzable. They are not the solu�ons to the standard par�al differen�al

equa�ons of mathema�cal physics for instance. Yet if these phenomena fail to sa�sfy the various external

constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will

not fix these kinds of difficul�es. The required design changes are likely to be so disrup�ve that the so*ware

requirements upon which the design is based and which provides the ra�onale for everything are violated.

Either the requirements must be modified, or a substan�al change in the design is required. In effect the

development process has returned to the origin and one can expect up to a 100-percent overrun in schedule

and/or costs.


Throughout the rest of his paper, Dr. Royce argues that taking the proper steps can mi#gate the risks

inherent in the Waterfall process. These steps include the following:

♦ Create “quite a lot” of documenta#on. Dr. Royce suggest 1500 pages for a $5 million

soJware development project. He comments that the amount of documenta#on needed is

“certainly more than most programmers, analysts, or program designers are willing to do if

leJ to their own devices.”

♦ Complete the en#re design before analysis and coding even begins.

♦ Expect to do your work twice. The first #me should be considered a trial run to shake-out

the requirements.

♦ Involve the customer.

How many Waterfall projects do you know about that started with this much documenta#on, has budget

and schedule to do the en#re project twice, and dictates that the customer will be involved throughout the

project? Common sense dictates that if we “fail to plan we should plan on failing,” and this idea is oJen used

to jus#fy the Waterfall methodology. However, what we oJen fail to consider when star#ng a project is

everything we don’t know that we don’t know (unknown-unknowns) and the magnitude of risk these

unknown-unknowns hold. Building in smaller increments allows us to validate and change our design as we

develop.

The Birth of ScrumThe Birth of Scrum

A couple decades aJer the publica#on of the Waterfall document, a new soJware development

framework was proposed that seemed to resolve many of the problems with the Waterfall methodology.

Under this new development paradigm, the en#re Waterfall process would be squeezed down to a very

short #me-box and repeated many #mes across a series of itera#ons called sprints. The focus on process and

documenta#on would be replaced with a focus on people and results.

To be clear, Scrum doesn’t do away with gathering requirements, design, or tes#ng. Instead, it argues that

doing these things, and all the other project work, in smaller chunks gives the project team feedback in a

more #mely manner and, therefore, increases quality and decreases risk.

An Overview of ScrumAn Overview of Scrum

Scrum was not developed as a fully defined process or methodology; rather it is a framework with just a

few hard and fast rules. For the most part, Scrum defines what needs to be done, not how to do it. According

to The Scrum Guide, Scrum is:

♦ Lightweight;

♦ Simple to understand;

♦ Extremely difficult to master.


The scrum framework is founded upon the empirical process control theory, or empiricism, which asserts

that knowledge is gained from sense experience, as compared to ra#onalism which espouses reason as the

means to knowledge. In other words, it assumes it is impossible to gather requirements up front by using

thought experiments and states that requirements must be found via the development experience.

Scrum is built upon a defined set of events, roles, and ar#facts that work together to streamline the

product development process. In fact, the main goal of Scrum is to achieve the highest business value in the

shortest amount of #me.

More about AgileMore about Agile

There are several frameworks that fit into the Agile space, but

Scrum is the best-known and most used. The Agile Manifesto

(www.AgileManifesto.org) states:

♦ Individuals and interac#ons are more important

than processes and tools;

♦ Working soJware is more important than

comprehensive documenta#on;

♦ Customer collabora#on is more important than

contract nego#a#on;

♦ Responding to change is more important than following a

plan.

Under the Agile umbrella, there are some frameworks that work well together and others that don’t.

Scrum works well with eXtreme Programming, but tends to conflict with Agile methodologies that recognize

the classical concept of project management. In Scrum, the team is self managing. No one person manages

the group.

The Stacey Agreement and Certainty MatrixThe Stacey Agreement and Certainty Matrix

Ralph Stacey devised the Agreement and Certainty Matrix

as a way of visualizing the rela#onship between agreement

and certainty. According to the matrix, ideas or projects that

have requirements that are well understood across the

organiza#on are simple. As disagreement increases, things

become more poli#cal. Uncertain projects with a large amount

of agreement are considered complicated. The remaining two

sec#ons represent moderate or higher uncertainty and

disagreement. If you get too far away from the Simple (bo-om

-leJ) corner, the project enters the area of Chaos.


Using the Stacey matrix as a guide, any project that would fall inside the Chaos arc is doomed to failure.

A smaller scale project that decreases the uncertainty and disagreement might be able to be carved out of

the project.

Projects that fall within the Simple arc are good candidates for the Waterfall methodology. A very high

degree of certainty means there will be few unknown-unknowns. This leaves the en#re central corridor

that would be best served by using an Agile approach.

The A-ributes of ScrumThe A-ributes of Scrum

Scrum defines 4 a-ribute types: Pillars, Roles, Events, and Ar#facts. Some texts define the Pillars

separately and add Values as the fourth type. These values: courage, commitment, respect, openness, and

focus, must be present in order to successfully complete a project using Scrum. Next we will go into more

detail on the a-ributes.

The Pillars of ScrumThe Pillars of Scrum

The three main pillars of Scrum are transparency,

inspec#on, and adapta#on.

TransparencyTransparency

Transparency means assuring a “mee#ng of the

minds” of all stakeholders. It includes using a common

language when discussing the project; open, frank

communica#on; and visible project progress.

Inspec#onInspec#on

Project quality is controlled via inspec#on. Unlike

Waterfall projects, Scrum projects don’t have a

separate tes#ng phase. Tes#ng is expected to be done throughout the project. Ini#al tes#ng is done by the

developer working on the feature. When they feel the feature is ready, they will hand it off to someone

else on the team for final tes#ng. User Acceptance Tes#ng is performed at the end of the Sprint during the

Sprint Review mee#ng.

Adapta#onAdapta#on

Adapta#on refers to any change that is made throughout the project. Changes to the Product Backlog,

Bug fixes, and process changes and other quality assurance ac#vi#es, and are all included in adapta#on.

According to The Scrum guide, there are four formal opportuni#es for inspec#on and adapta#on:


♦ Sprint Planning Mee#ng

♦ Daily Scrum

♦ Sprint Review

♦ Sprint Retrospec#ve

We will go into these in more detail in the sec#on on Events.

The Roles in ScrumThe Roles in Scrum

Scrum defines three core roles: Product Owner, Scrum Master, and Development Team Member; and

eludes to a fourth, the Stakeholder.

Product OwnerProduct Owner

The Product Owner is, or at least should be, someone from the business that has a vested interest in the

project; someone that has the authority to commit resources and make decisions about what the systems

will do, and how it will do it.

The Product Owner (PO) is also responsible for determining the Return on Investment for the project.

Working with the Scrum Master and Development Team, the PO determines the cost, based upon the

percentage of a Sprint the feature will take to complete—this becomes the Investment. The Return is a li-le

more difficult to determine because the PO has to assign a value to the feature.

Once all of the Returns (feature values) have been calculated, a total project Return can be calculated by

summing the individual values.

Product BacklogProduct Backlog

The product backlog is the tool the Product Owner uses to document the system features. Product backlog

items, usually wri-en as user stories, can be added to the product backlog by anyone, at any #me. The

Product Owner is responsible for

determining the value of each item and the

priority in which it will be developed. They

also decide when enough value has been

built and closes the project. A typical

Waterfall project will start with a desired

set of features (scope), and will then

es#mate a budget and schedule. However,

a Scrum project will normally start with a

defined budget and #meline and then the

team will determine the scope that can be

created in that amount of #me.


AvailabilityAvailability

In order to realize the benefits of Scrum, it is impera#ve that the Product Owner be available to the team.

The Scrum Product Owner is is the main repository to the requirements and design. In Scrum, all ques#ons go

to the Product Owner; in Waterfall, if it isn’t in the design document then it doesn’t get put into the soJware.

So it is important that the Product Owner is seen by the organiza#on as an integral member of the team.

Someone with five or ten hours per week available to work on the project is not a good candidate.

Scrum MasterScrum Master

The Scrum Master is a servant leader. They should be willing an able to do virtually anything that needs to be

done that can’t, shouldn’t, or won’t be done by anyone else.

The Scrum Master and the Development TeamThe Scrum Master and the Development Team

The Scrum Master provides several services to the Development Team, including:

• Referee—ensuring the Scrum rules are followed;

• Coach—helping team understand Scrum;

• Blocker—clears impediments. The Scrum Master is responsible for making sure the

Development Team can focus on building value into the soJware. Any other tasks that come

their way are quickly deflected to the Scrum Master to address;

• Facilitator—facilitates mee#ngs as necessary;

• Guide—understands and communicates vision, goals, and requirements to the Development

Team.

The Scrum Master and the Product OwnerThe Scrum Master and the Product Owner

The Scrum Master assists the Product Owner in several tasks. Typically, the Scrum Master will have more

experience and/or training in Scrum and will help guide the Product Owner. They might also act as assistant

product owner, answering the Development Team’s ques#ons and only going to the Product Owner when

something new comes up. The Scrum Master helps the Product Owner with whatever needs to be done in

order to make the project a success, including:

• Assistant—assis#ng with Product Backlog maintenance tasks. The Scrum Master should have

knowledge and tools available that can help streamline the Product Backlog tasks;

• Planner—assis#ng with long-term product planning. The Scrum Master spends most of their #me

with the team and should be able to represent the team in long-term planning sessions;

• Coach--the Scrum Master should be an expert in Scrum. Product Owners oJen have a limited

amount of experience in Scrum and can benefit from the Scrum Master’s experience;

• Facilitator—the Scrum Master will help the Product Owner with facilita#on as needed.

The Scrum Master and the Organiza#onThe Scrum Master and the Organiza#on

While the Scrum Master is mostly focused on the project, there are oJen opportuni#es to provide assistance


to the organiza#on. The Scrum Master might spend a small amount of their #me working outside of the

project on tasks such as:

• Evangelist—helping the organiza#on to adopt Scrum;

• Planner—planning Scrum implementa#on within the organiza#on;

• Assistant—helping the organiza#on increase their effec#ve use of Scrum.

Development TeamDevelopment Team

The Development Team is responsible for doing the work of the project. The team is small, self-organizing,

egalitarian, cross-func#onal, and atomic.

SmallSmall

The Development Team should be between five and nine people. Fewer than five won’t give the team the

agility they need and more than nine is too difficult to self-manage.

SelfSelf--organizingorganizing

The Development Team is self-organizing. There is no manager to dictate how the team should operate.

They are given the goal of crea#ng the most value as quickly as possible and it is up to them to figure out the

best way to make it happen. It is common for a team to take three to six weeks to become cohesive and high-

func#oning.

EgalitarianEgalitarian

Everyone on the Development Team has the same role: Development Team member. Leaders may

emerge, but they are considered leaders of equals and not managers.

CrossCross--func#onalfunc#onal

Everyone on the Development Team is responsible for all tasks. Unlike a Waterfall project, a database task

won’t necessarily be done by the team’s DBA; a tes#ng task won’t necessarily be done by the team’s QC

expert. Every task is assigned to maximize overall velocity. Some#mes this means one par#cular tasks might

be done by the non-expert.

In prac#ce, this might manifests itself in one or more of the following ways:

• A QC person may sit with a developer to do pair programming. The developer does most of

the coding, but explains the code logic along the way. The QC person watches for logic

problems that could introduce bugs into the system.

• A developer may be assigned to write a SQL Script that is then reviewed by the database

expert before it is considered finished.

• A business analyst that wants to learn HTML 5 may take a crack at the user interface while

everyone else is working on other func#onality, then the UI expert will sit down with them and

help them work through any problems they might have.


AtomicAtomic

There is one Development Team. There are no sub-teams working on different layers or different

technologies.

StakeholderStakeholder

A stakeholder of an Agile project is defined in the same way as for a Waterfall project. It is anyone

interested in the success (or, possibly, failure) of the project. Their sole responsibility is to act as subject

ma-er experts, assis#ng the Product Owner to steer the course of the project. They accomplish this by

sending feature requests to the Product Owner, and providing feedback during the project review mee#ngs.

Scrum EventsScrum Events

Scrum defines five main events. Other events can be added; and they may be divided differently, but all

events defined in the Scrum framework are integral to the process and should be held.

SprintSprint

A sprint, which is also referred to as an itera#on, is a consistent, #me-boxed interval of #me that contains

all other events. At the beginning of the sprint, the team will define what they will get done. At the end of the

sprint, the team delivers everything they have completed. The project is made up of several sprints.

Sprints are oJen set at two weeks. However, they can be any length of #me, but shouldn’t be longer than

four weeks.

Rules for sprints include:

• The composi#on of the team can not change during the sprint. Team members may have

scheduled or un-scheduled #me off, but new people should not be added to the team in the

middle of a sprint; nor should people on the team be asked to work on anything that is not

part of the project.

• Each sprint should be given a pass/fail grade at its conclusion. The scrum team determines the

metric used to determine pass/fail at the beginning of the project.

• Each sprint is expected to result in a Poten#ally Shippable Product Increment. This increment

should be something that could be promoted into the produc#on environment, but it doesn’t

actually have to be promoted.

• Items can not be added to the Sprint Backlog once the Sprint Planning Mee�ng is over un#l all

planned work is completed.

Sprint Planning Mee#ngSprint Planning Mee#ng

The Sprint Planning Mee�ng is tradi#onally divided into two parts. However, some prac##oners consider

the two parts separate events.


The first part is the sprint selec#on mee#ng. During this mee#ng, the Product Owner, Scrum Master, and

Development Team will select those items from the product backlog that will be worked on during the sprint.

This mee#ng is #me-boxed at 2 hours per week of sprint. This mee#ng can be considered the requirements

gathering for the sprint as it focuses on what will be build during the next sprint.

During the second part of the sprint planning mee#ng, the team will work on design considera#ons and

will determine how the work will be done. This mee#ng is also #me-boxed at 2 hours per week of sprint.

Daily Scrum Mee#ngDaily Scrum Mee#ng

The daily scrum mee#ng is held at the same #me and same place every day. Anyone

can a-end, but the Development Team are the only people invited to speak. The #me

box (15 minutes) is strictly enforced. This mee#ng should not be considered a status

update mee#ng. Nor is it a technical design mee#ng. The only thing that is discussed

are the answers to three ques#ons:

1. What got done yesterday

2. What will get done today

3. What is keeping us from making progress

The Development Team will determine the exact format for the mee#ng, for instance whether each

person answers the three ques#ons about themselves or if the ques#ons are asked in reference to each of

the sprint backlog items.

Sprint Review Mee#ngSprint Review Mee#ng

A review mee#ng is held at the end of each sprint to allow the team to review the completed work with

the stakeholders. During this mee#ng, the Product Owner will demonstrate the new

func#onality and then the floor will be opened for discussion. Requested changes will

be documented as new product backlog items. At the end of the mee#ng, the Product

Owner will officially accept those product backlog items that are deemed to have been

completed. Any product backlog items that are not accepted are put back on the

product backlog list.

Anyone can a-end the Sprint Review Mee�ng. The Product Owner and Scrum Master facilitate, and the

Development Team must be present to answer ques#ons. All stakeholders are op#onal, but are encouraged

to a-end.

The Sprint Review Mee�ng is #me-boxed at one hour per week of sprint.

Sprint Retrospec#ve Mee#ngSprint Retrospec#ve Mee#ng

The Sprint Retrospec�ve Mee�ng is used to make changes to the team processes as a method of


con#nuous improvement. The full Development Team is required and the Scrum Master

typically facilitates. The mee#ng discusses any topic that is thought to affect how the team

operates, including: rela#onships, processes, tools, work assignments, etc…

The Sprint Retrospec�ve Mee�ng is #me-boxed to 45 minutes per week of sprint.

Ar$factsAr$facts

Scrum defines three required ar#facts, the Product Backlog, Sprint Backlog, and the Increment. Think of

the Product Backlog as the en#re list of all features that are desired by someone. Nothing that is not in the

Product Backlog will ever make it into the product. The Sprint Backlog is everything from the Product Backlog

that the team has decided it will work on during the current Sprint.


A-ributes of a Product Backlog:

• List of everything that might be needed in the project

• Ordered by the Product Owner based upon ROI

• The single source of requirements. If it isn’t on this list, it will not be in the product

• Owned and maintained by the Product Owner with input from all stakeholders.

• Each PBI include a descrip#on, order, and es#mate.

Sprint BacklogSprint Backlog

A-ributes of a Sprint Backlog:

• Items from the product backlog that

have been scheduled to be

completed during the current sprint;

• Broken down by the Development

Team into tasks;

• Must be small enough to be done

within one sprint;

• Must be tracked somehow. Usually

tracked on a task board.

IncrementIncrement

The Increment is the sum of all product backlog

items that have been completed during a sprint that were accepted by the Product Owner. The sum of all

Sprint Increments make up the product.


BibliographyBibliography

www.Scrum.orgwww.Scrum.org

Scrum.org is the home of Scrum, and is leading the evolu#on and maturity of Scrum to im-

prove the profession of soJware development.

Scrum.org was founded in 2009 by Ken Schwaber, one of the creators of Scrum, along

with Alex Armstrong, out of extreme dissa#sfac#on with the state of the art.

www.ScrumAlliance.comwww.ScrumAlliance.com

The Scrum Alliance is a non-profit professional membership organiza#on created to share

the Scrum framework and transform the world of work.

Scrum.JeffSutherland.comScrum.JeffSutherland.com

Jeff created the first Scrum team in 1993 and worked with Ken Schwaber to formalize Scrum

at OOPSLA'95. Together, they extended and enhanced Scrum at many soJware companies,

helped write the Agile Manifesto in 2001, and authored the Scrum Guide.

www.ScrumShortcuts.comwww.ScrumShortcuts.com

Scrum focused blog wri-en and maintained by Ilan Goldstein.

h�p://www.mountaingoatso,ware.com h�p://www.mountaingoatso,ware.com

Mountain Goat SoJware founder Mike Cohn helps companies adopt and improve their use

of agile processes and techniques in order to build extremely high performance develop-

ment organiza#ons.



GlossaryGlossary

Daily Scrum Mee#ngDaily Scrum Mee#ng

A daily mee#ng in which each development team member reviews what they accomplished yesterday,

commits to the team what they will get done today, and announces any known impediments (barriers) to

the project. The Daily Scrum Mee#ng is not a status update mee#ng for the benefit of management. It is

a #me for the development team members to commit to a block of work.

Development TeamDevelopment Team

A small, self-organizing, egalitarian, cross-func#onal, atomic team that creates the product.

Poten#ally Shippable Product IncrementPoten#ally Shippable Product Increment

The end result of a sprint. Everything that is completely done that could be released into produc#on if the

Product Owner chose to release it.


Every feature that could be put into the product. If it isn’t on the Product Backlog list, it won’t be in the

product. The Product Backlog list is maintained and sorted by the Product Owner.

Product Backlog ItemProduct Backlog Item

A single item from the Product Backlog. The team selects items from the product backlog to be moved

into the Sprint for development.

Product OwnerProduct Owner

The single-point-of-contact for all feature and requirements ques#ons from the development team. This

is a single individual, not a commi-ee, that has the authority to make decisions on behalf of the organiza-

#on in regard to the project’s product.

Scrum MasterScrum Master

A jack-of-all-trades type person that enables the project by protec#ng the development team and resolv-

ing impediments.

SprintSprint

A fixed #me-box that the development team works on a poten#ally shippable product increment. Sprints

can be any length of #me that the team choses, but should never be more than 4 weeks.


Sprint BacklogSprint Backlog

The complete list of items that were selected from the product backlog to be worked on during the cur-

rent sprint. During the promo#on process from product backlog to sprint backlog, the product backlog

items are clarified and the details are fleshed out. The product backlog items are also oJen broken up

into smaller pieces so they can be worked on in smaller chunks.

Sprint Backlog ItemSprint Backlog Item

A single item from the Sprint Backlog that represents about 1/2 day of work.

Sprint Planning Mee#ngsSprint Planning Mee#ngs

The sprint planning mee#ngs are the first two mee#ngs of the sprint.

The first mee#ng is the sprint item selec#on mee#ng. During this mee#ng, the team decides which prod-

uct backlog items will be added to the sprint backlog. This mee#ng focuses on what will be built during

the sprint.

The second mee#ng is the sprint design mee#ng. During this mee#ng the development team digs deeper

into the sprint backlog items and designs the solu#on. This mee#ng focuses on how each sprint backlog

items will be built.

Sprint Retrospec#ve Mee#ngSprint Retrospec#ve Mee#ng

The final mee#ng at the end of the sprint. The purpose of this mee#ng is for the team to make changes to

their processes in order to increase their speed and/or quality.

Sprint Review Mee#ngSprint Review Mee#ng

The mee#ng at the end of the sprint in which the team demonstrates the work that was completed dur-

ing the sprint. At the end of this mee#ng, the product owner will announce which sprint backlog Items

are complete and can be considered part of the poten#ally shippable product increment.

StakeholdersStakeholders

A Stakeholder is anyone that has a stake in the project, including: management, end users, IT support,

and any other interested par#es.

TeamTeam

The team is the full project team: product owner, scrum master, and development team. Team is also

some#mes used to refer to the development team, so it would be wise to what team is meant if the con-

text doesn’t make it clear.

Scrum@Perficient

Date post:	13-Jun-2020
Category:	Documents
Upload:	others
View:	10 times
Download:	0 times

Scrum@Perficient · Scrum@Perficient Scrum@Perficient A quick guide for anyone involved in a Scrum...

Documents