SCRUM 101 - "The Scrum Guide" - Teacher's Cut

SCRUM 101
“THE SCRUM GUIDE”
© Catarina Reis Advanced Topics in Software Engineering - ESTG - IPLeiria - 2016/2017
TEACHER’S CUT

ADVANCED TOPICS IN SOFTWARE ENGINEERING
TÓPICOS AVANÇADOS DE ENGENHARIA DE SOFTWARE
Engenharia Informática - 3º ano - 1º semestre
Departamento de Engenharia Informática
Escola Superior de Tecnologia e Gestão
Instituto Politécnico de Leiria
Catarina Reis
catarina.reis@ipleiria.pt
reiscatarina
@catarina_reis

SCRUM

PEOPLE AND HISTORY

Ken Schwaber Jeff Sutherland
‣ OOPSLA - 1995
‣ “The Scrum Guide” - http://www.scrumguides.org

July 2016

Developed and sustained by Ken Schwaber and Jeff Sutherland

The Definitive Guide to Scrum:
The Rules of the Game

July 2016

Developed and sustained by Ken Schwaber and Jeff Sutherland

DEFINITION

Scrum (n): A framework within which people can
address complex adaptive problems, while
productively and creatively delivering products of
the highest possible value.
‣ not a process or a technique for building products —> a framework within
which you can employ various processes and techniques.
‣ Scrum Teams and roles, events, artifacts, and rules.

THEORY

‣ Empirical process control theory
‣ Iterative and incremental approach to optimize
predictability and control risk
‣ Three Pillars
‣ Transparency
‣ Inspection
‣ Adaptation

VALUES

Commitment
Courage
Focus
Openness
Respect

THE FRAMEWORK

SPRINT
SPRINT
PLANNING
DAILY
SCRUM
SPRINT REVIEW
SPRINT
RETROSPECTIVE
SPRINT
BACKLOG
MONITORING
CHARTS
PRODUCT
INCREMENT
PRODUCT
BACKLOG
PRODUCT
OWNER
SCRUM
MASTER
DEVELOPMENT
TEAM

SCRUM TEAM

ROLES

PRODUCT OWNERSCRUM MASTER
DEVELOPMENT TEAM© Catarina Reis Advanced Topics in Software Engineering - ESTG - IPLeiria - 2016/2017

PRODUCT OWNER

PRODUCT OWNER
‣ maximize value of the product and
of the development team
‣ one person
‣ respect! development team only
works with his requirements
‣ responsible for managing the
product backlog
• clearly expressing the items
• ordering the items
• optimising value
• product backlog is visible, transparent and
clear to the SCRUM Team

DEVELOPMENT TEAM

DEVELOPMENT TEAM
‣ professionals who do the work
‣ work == deliver potentially releasable
increment of “Done” product
‣ self-organising and cross-functional

DEVELOPMENT TEAM
‣ no titles! —> everyone is a “developer”
‣ no sub-teams!
‣ accountability belongs to the Development
Team (as a whole)

DEVELOPMENT TEAM
size? “small enough to remain nimble and large
enough to complete signiﬁcant work within a Sprint.”
[3, 9]
interaction
productivity gains
skill constraints
coordination
complexity

SCRUM MASTER

SCRUM MASTER
‣ ensuring Scrum is understood and
enacted
‣ servant-leader
‣ one person
‣ helps everyone understand and
change their interactions with the
Scrum Team
‣ maximize value created by the
Scrum Team

SCRUM MASTER
‣ ﬁnding techniques for effective
product backlog management
‣ clear and concise backlog items
‣ product planning in an empirical
environment
‣ arrange product backlog to
maximize value
‣ understand agility and practice it!
‣ facilitating scrum events (on
demand or when needed)PRODUCT OWNER

SCRUM MASTER
‣ coaching
‣ self-organising and cross-
functional
‣ protecting the team
‣ create high-value products
‣ remove impediments
‣ facilitating scrum events (on
demand or when needed)
DEVELOPMENT TEAM

SCRUM MASTER
‣ leading and coaching the Scrum
adoption
‣ planning Scrum implementations
‣ helping everyone understand and
enact upon Scrum
‣ presenting the productivity
increase of the Scrum Team
‣ working to increase the overall
effectiveness of the organisationORGANISATION

SCRUM TEAM
‣ self-organising
‣ cross-functional
‣ deliver products iteratively and
incrementally maximising opportunities
for feedback

EVENTS

SPRINT
SPRINT
PLANNING
DAILY
SCRUM
SPRINT REVIEW
SPRINT
RETROSPECTIVE

SPRINT

SPRINT
‣ one month or less
‣ creation of potentially releasable
product increment - SPRINT GOAL
‣ no changes that endanger the sprint
goal allowed
‣ scope clariﬁed (and re-negotiated) as
the work evolves
‣ contains all other events

SPRINT
‣ sprints have equal durations during
development
‣ sprint ends >>> new sprint begins
‣ quality goals (keep)
‣ enable predictability
‣ limit risk

SPRINT
CANCELLED
‣ whom? Product Owner
‣ why? Sprint Goal becomes
obsolete
‣ traumatic and very uncommon

SPRINT
PLANNING

SPRINT
PLANNING
‣ maximum of 8 hours (to a 1 month Sprint)
‣ plan the work to be performed in the Sprint
‣ collaboration of the entire Scrum Team

SPRINT
PLANNING
‣ Development Team
‣ forecasts the functionality to
develop in the Sprint
‣ Product Owner
‣ proposes the Sprint Goal by
selecting the Product Backlog
items
INPUTS
• Product Backlog
• Latest Product
Increment
• Projected capacity of
Development Team
• Past performance of
Development Team
OUTPUT
SPRINT GOAL
What can be done this Sprint?

SPRINT
PLANNING
‣ designs the system and the work to
produce a product increment
‣ decomposes work to units of 1 day or
less (tasks)
‣ external assistance
‣ Product Owner
‣ helps to clarify the items and makes
trade-offs
INPUTS
• Product Backlog
Items for the Sprint
• Sprint Goal
OUTPUT
SPRINT BACKLOG
How will the chosen work get done?

DAILY
SCRUM

DAILY SCRUM
‣ 15 minute time-boxed event
‣ held at the same time and place each day
‣ Development Team synchronises
‣ Inspecting the work since the last Daily Scrum
‣ Forecasting the work to be done before the
next Daily Scrum

‣ 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?
‣ Do I see any impediment that prevents me or
the Development Team from meeting the Sprint
Goal?
DAILY SCRUM

SPRINT REVIEW

SPRINT REVIEW
‣ held at the end of each Sprint
‣ presentation of the Increment to elicit feedback
and foster collaboration
‣ attendees: Scrum Team and invited
stakeholders

SPRINT REVIEW
INPUTS
• Product Backlog
Items - “Done”
or !”Done”
• Product Increment
OUTPUT
PRODUCT BACKLOG -
REVISED
‣ demonstrates the Product
Increment
‣ Product Owner
‣ explains the Product Backlog
status
‣ ALL: revise the Product Backlog
Collaboration

SPRINT
RETROSPECTIVE

SPRINT
RETROSPECTIVE
‣ held at the end of each Sprint Review
‣ Scrum Team
‣ Inspects how the last Sprint went with regards to
people, relationships, process, and tools
‣ Identiﬁes and orders the major items that went well
and potential improvements
‣ Creates a plan for implementing improvements

‣ create regularity and minimize the need
for meetings
‣ time-boxed events (maximum duration)
‣ formal opportunity to inspect and
adapt
‣ enable transparency
EVENTS

ARTIFACTS

SPRINT
BACKLOG
MONITORING
CHARTS
PRODUCT
INCREMENT
PRODUCT
BACKLOG

PRODUCT
BACKLOG

PRODUCT
BACKLOG ‣ ordered list of items
‣ everything that might be needed in the product
‣ single source of requirements
‣ never complete
‣ ﬁrst layouts the initially known and well understood
requirements
‣ evolves with the product and with the surrounding
environment - dynamic
PRODUCT
OWNER

PRODUCT
BACKLOG ‣ lists all features, functions, requirements,
enhancements and ﬁxes of the product
‣ each item has a description, order,
estimate and value (and occasionally, a
group)
‣ living artifact
PRODUCT
OWNER

PRODUCT
BACKLOG ‣ adding detail, estimates and order to the items
‣ ongoing process
‣ items reviewed and revised
‣ when? Scrum Team decides - no more than
10%
‣ “Ready” implies that a item can be selected for
a Sprint to be “Done” (enough detail is
included)
PRODUCT
OWNER
Reﬁnement

MONITORING
CHARTS

MONITORING
CHARTS
‣ burndowns / burnups /cumulative ﬂow
‣ compare the amount of work done and the
remaining
‣ improve transparency
“In complex environments, what will happen is
unknown. Only what has happened may be used
for forward-looking decision-making.”

SPRINT
BACKLOG

SPRINT
BACKLOG
‣ forecast of the functionality included in the next
product increment
set of Product Backlog items selected for the Sprint
+
a plan for delivering the product Increment and realising
the Sprint Goal
‣ highly visible, real-time picture of the work to
be accomplished during the Sprint

SPRINT
BACKLOG
DEVELOPMENT TEAM
DURING THE SPRINT

PRODUCT
INCREMENT

PRODUCT
INCREMENT
‣ sum of all the Product Backlog items
completed during a Sprint and the value of the
increments of all previous Sprints
‣ must be “Done” at the end of a Sprint
‣ must be in a useable condition (meet the
“Deﬁnition of Done”) regardless of the
Product Owner’s acceptance

‣ represent work or value
‣ provide and maximize transparency
‣ provide opportunities to inspect and
adapt
ARTIFACTS

DEFINITION OF DONE

‣ everyone must understand what “Done” means
‣ used to assess that the work is complete on the
product increment
‣ varies from team to team
‣ each Increment is additive to all prior
Increments and thoroughly tested, ensuring
that all Increments work together
DEFINITION OF “DONE”

SCRUM 101 - "The Scrum Guide" - Teacher's Cut

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to SCRUM 101 - "The Scrum Guide" - Teacher's Cut

Similar to SCRUM 101 - "The Scrum Guide" - Teacher's Cut (20)

Recently uploaded

Recently uploaded (16)

SCRUM 101 - "The Scrum Guide" - Teacher's Cut