Upload
others
View
22
Download
0
Embed Size (px)
Citation preview
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 2
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 3
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 4
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:
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 5
♦ 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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 6
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
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 7
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 8
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 9
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
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 10
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.
Product BacklogProduct Backlog
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 11
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 12
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 13
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.
Product BacklogProduct Backlog
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.
Scrum@Perficient—A quick guide for anyone involved in a Scrum project at Perficient � 14
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