Scrum Guide Notes
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 8
Scrum Guide Notes
Vasileios Papadopoulos
Agile Software Development
- A different approach to the software develop-
ment process
- Focuses on the clean delivery of individual
pieces or parts of the software and not on the
entire application
- Requirements & solutions evolve through the
collaborative effort of teams and their cus-
tomers and/or end users
- Encourages early delivery and continuous im-
provement
- The term Agile was popularized in 2001 when
the Agile Manifesto was published
Agile Manifesto
-Individuals and interactions
over processes and tools
-Working software
over comprehensive documentation
-Customer collaboration
over contract negotiation
-Responding to change
over following a plan
Definition of Scrum
Scrum (n): A framework within which people
can address complex adaptive problems, while
productively and creatively delivering products
of the highest possible value.
What is a framework?
A framework is a system of rules, ideas, or be-
liefs that is used to plan or decide something.
Note
As a framework, Scrum will never provide
you with exact processes or show you ex-
actly how to deal with problems. Instead,
it provides a set of rules and relies on the
team to find the best possible solution
Concept
- Small team of people that is highly flexible
and adaptive
- Employ an iterative, incremental approach to
optimize predictability and control risk
- Make decisions based on empirical process
control theory, or empiricism
Empiricism
Knowledge comes from experience and making
decisions on what is known.
Scrum Consists of
- Roles
- Events
- Artifacts
- Rules
Scrum Optimizes
- Flexibility
- Creativity
- Productivity
Three Pillars of Scrum
-Transparency
Make significant aspects of the process visible
to those responsible for the outcome
Page 1 of 8
-Inspection
Frequently inspect the progress towards a goal
to detect undesirable variances
-Adaption
Adjust the process as soon as possible to min-
imize further deviation
Scrum Values
-Commitment
People personally commit to achieving the
goals of the Scrum Team
-Courage
The Scrum Team members have courage to do
the right thing and work on tough problems
-Focus
Everyone focuses on the work of the Sprint
and the goals of the Scrum Team
-Openness
The Scrum Team and its stakeholders agree to
be open about all the work and the challenges
with performing the work
-Respect
Scrum Team members respect each other to
be capable, independent people
The Scrum Team
- Product Owner
- Development Team
- Scrum Master
Note
Be careful not to confuse the Scrum Team
with the Development Team. The Scrum
Team contains the Development Team,
along with the Product Owner and the
Scrum Master
Scrum Team Characteristics
- Deliver products iteratively and incrementally
- Self-organizing
- Cross-functional
Self-organization
Self-organizing teams choose how best to accom-
plish their work, rather than being directed by
others outside the team.
Cross-functionality
Cross-functional teams have all competencies
needed to accomplish the work without depend-
ing on others not part of the team.
The Product Owner
- Responsible for maximizing the value of the
product resulting from work of the Develop-
ment Team
- One person, not a committee
- The only person responsible for managing the
Product Backlog. They have the final say on
its content and ordering and everyone must
respect their decisions
Note
The Product Owner may have the Devel-
opment Team or someone else manage the
Product Backlog. They, however, remain
accountable
Product Backlog
- A prioritized list of desired product function-
ality
- Provides a shared understanding of what is
needed in the product and in which order
Product Owner - Product Backlog
- Clearly express Product Backlog Items
- Order the items in the Product Backlog to
best achieve goals and missions
- Optimize the value of work the Development
Team performs
- Ensure that the Product Backlog is visible,
transparent, clear to all and shows what the
Scrum Team will work on next
Page 2 of 8
- Ensure that the Development Team under-
stands the Product Backlog to the level
needed
The Development Team
- Consists of professionals who do the work of
delivering a potentially releasable Increment of
“Done” product at the end of each Sprint
- Only members of the Development Team cre-
ate the Increment
- Size: 3 to 9 members
Note
The Scrum Guide suggests to have a De-
velopment Team of 3 to 9 members but
this is not a requirement. A Development
Team can still have 15 members however,
it won’t be as effective.
Development Team Characteristics
- Self-organizing
- Cross-functional
- Scrum recognizes no titles for Development
Team members
- Scrum recognizes no sub-teams in the Devel-
opment Team
- Accountability belongs to the team as a
whole
The Scrum Master
- Promotes and supports Scrum
- Helps everyone understand Scrum theory,
practices and rules
- Acts as a Servant-Leader for the Scrum Team
- Helps those outside the Scrum Team under-
stand which interactions are helpful and which
aren’t
Note
As servant-leader the Scrum Master guides
and coaches the Scrum Team. They are
not allowed, however, to tell the team what
to do or how to do it unless related to the
Scrum framework
Scrum Master - Product Owner
- Ensure that goals, scope, and product domain
are understood by everyone on the Scrum
Team as well as possible
- Find techniques for effective Product Backlog
management
- Help the Scrum Team understand the need for
clear and concise Product Backlog Items
- Ensure the Product Owner knows how to ar-
range the Product Backlog to maximize value
- Understand product planning in an empirical
environment
- Understand and practice agility
- Facilitate Scrum events as requested or needed
Scrum Master - Development Team
- Coach the Development Team in self-
organization and cross-functionality
- Help the Development Team create high-value
products
- Remove impediments to the Development
Team’s progress
- Facilitate Scrum events as requested or needed
- Coach the Development Team in organiza-
tional environments in which Scrum is not yet
fully adopted and understood
Scrum Master - Organization
- Lead and coach the organization in its Scrum
adoption
- Plan Scrum implementations within the orga-
nization
- Help employees and stakeholders understand
and enact Scrum and empirical product de-
velopment
- Cause change that increases the productivity
of the Scrum Team
- Work with other Scrum Masters to increase
the effectiveness of the application of Scrum
in the organization
Page 3 of 8
Scrum Events
- The Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Scrum Event Characteristics
- Create regularity
- Minimize the need for meetings not defined in
Scrum
- Time-boxed (have max duration)
- Each event is an opportunity to inspect and
adapt something
- Failure to include any of these events results
in reduced transparency
The Sprint
- Acts as a container for all other events
- Duration: One month or less (consistent du-
ration)
- A new sprint starts immediately after the con-
clusion of the previous Sprint
- A “Done”, potentially releasable Product In-
crement is created
- Consists of:
–Sprint Planning
–Daily Scrums
–Development Work
–Sprint Review
–Sprint Retrospective
During the Sprint
- No changes are made that would endanger the
Sprint Goal
- Quality goals do not decrease
- Scope may be clarified and re-negotiated be-
tween the Product Owner and the Develop-
ment Team as more is learned
Cancelling a Sprint
-Only the Product Owner has the authority
to cancel a Sprint
- The Sprint is cancelled if the Sprint Goal be-
comes obsolete
- Any completed and “Done” Product Backlog
items are reviewed
- If part of the work is potentially releasable,
the Product Owner typically accepts it
- All incomplete Product Backlog Items are re-
estimated and put back on the Product Back-
log
Note
Sprint cancellations are often traumatic to
the Scrum Team and should be avoided.
They also consume resources as everyone
regroups in another Sprint Planning to
start another Sprint.
Sprint Planning
- What can be delivered in the Increment re-
sulting from the upcoming Sprint?
- How will the work needed to deliver the In-
crement be achieved?
- The plan is created by the collaborative work
of the entire Scrum Team
- Max duration: 8 hours for one-month Sprint
- Attendees: All Scrum Team members
Sprint Planning - Input
- Product Backlog
- Latest Product Increment
- Projected capacity of the Development Team
during the Sprint
- Past Performance of the Development Team
Sprint Planning - Notes
- The number of items selected from the Prod-
uct Backlog for the Sprint is solely up to the
Development Team
Page 4 of 8
- The Product Owner can help to clarify se-
lected Product Backlog Items and make trade-
offs
- The Development Team may renegotiate se-
lected Product Backlog Items with the Prod-
uct Owner
- The Development Team may invite other peo-
ple to attend to provide technical or domain
advice
- Output: Sprint Backlog and Sprint Goal
Sprint Backlog
- The Product Backlog Items selected for this
Sprint
- A plan for delivering them
Sprint Goal
- An objective that will be met within the
Sprint through the implementation of the se-
lected Product Backlog Items
- Provides guidance to the Development Team
on why it is building the Increment
- Created by the entire Scrum Team
Note
Although Sprint Planning starts by hav-
ing the Product Owner discuss the objec-
tive that the Sprint should achieve and the
Product backlog Items that, if completed
during the Sprint, would achieve the Sprint
Goal, the final Sprint Goal is created by
the collaborative effort of the entire Scrum
Team
Daily Scrum
- Held every day of the Sprint at the same place
and time
- The Development Team plans work for the
next 24 hours
- Max duration: 15 minutes
- Attendees: All Development Team members
Daily Scrum - Notes
- The Scrum Master ensures that the Develop-
ment Team has the meeting but the Develop-
ment Team is responsible for conducting
the Daily Scrum
- The Scrum Master teaches the team to keep
the Daily Scrum within the 15-minute time-
box
- The Development Team or team members of-
ten meet immediately after the Daily Scrum
for related discussions
- It is an internal meeting for the Development
Team. If others are present, the Scrum Master
ensures they do not disrupt the meeting
Daily Scrum - Benefits
- Improve communications
- Eliminate other meetings
- Identify impediments to development for re-
moval
- Highlight and promote quick decision-making
- Improve the Development Team’s level of
knowledge
Sprint Review
- Held at the end of each Sprint
- Inspect the Increment and adapt the Product
Backlog if needed
- Collaborate on the next things that could be
done to optimize value
- Max duration: 4 hours for a one-month Sprint
- Attendees: All Scrum Team members and
Stakeholders
(Invited by the Product Owner)
Sprint Review - Notes
- The Sprint Review is not a demo
- The presentation of the Increment is intended
to elicit feedback and foster collaboration
- Output: A revised Product Backlog that de-
fines the probable Product Backlog Items for
the next Sprint
Page 5 of 8
Scrum Master - Sprint Review
- Ensure that the event takes place
- Everyone should understand its purpose
- Teach everyone to keep it within the time-
limit
Sprint Retrospective
- Occurs after the Sprint Review and prior to
the next Sprint Planning
- Identify how the last Sprint went with regards
to people, relationships, processes and tools
- Identify and order the major items that went
well and potential improvements
- Create a plan for implementing improvements
to the way the Scrum Team does its work
- Max duration: 3 hours for a one-month Sprint
- Attendees: All Scrum Team members
Scrum Master - Sprint Retrospective
- Ensure that the event takes place and atten-
dants understand its purpose
- Ensure that the meeting is positive and pro-
ductive
- Teach everyone to keep it within the time-box
- Participate as peer team member from the ac-
countability over the Scrum process
- Encourage the Scrum Team to improve
Note
During each Sprint Retrospective, the
Scrum Team plans ways to increase prod-
uct quality by improving work processes or
adapting the definition of “Done” if appro-
priate and not in conflict with the product
or organizational standards
Scrum Artifacts
- Product Backlog
- Sprint Backlog
- Increment
Product Backlog
- Ordered list of everything known to be needed
in the Product
- Single source of requirements for any changes
to be made to the Product
- Dynamic (it evolves)
- It is never complete
- If a Product exists, a Product Backlog exists
too
Note
If multiple Scrum Teams work on the same
Product, only one Product Backlog is
used
Product Backlog Items
- Product Backlog items that will occupy the
Development Team for the upcoming Sprint
are refined so that any one item can reason-
ably be “Done” within the Sprint
- Product Backlog items that can be “Done”
by the Development Team within one Sprint
are deemed “Ready” for selection in a Sprint
Planning
Note
Product Backlog Items can be updated
anytime by the Product Owner or at the
Product Owner’s discretion
Product Backlog Items - Attributes
- Description
- Order
- Estimate
- Value
- May also include test descriptions that will
prove the item’s completeness when “Done”
Product Backlog Refinement
- The act of adding detail,estimates, and or-
der to items in the Product Backlog
Page 6 of 8
- The Product Owner and the Development
Team cooperate during refinement
- The Scrum Team decides how and when re-
finement is done
-Usually consumes no more than 10% of the
Development Team’s capacity
Note
It is the sole responsibility of the Develop-
ment Team to estimate items in the Prod-
uct Backlog. Although the Product Owner
may influence the team by helping it un-
derstand and select trade-offs, the people
who will perform the work make the final
estimate
Sprint Backlog
- The set of Product Backlog Items selected for
the Sprint
- A plan for delivering the Increment and real-
izing the Sprint Goal
- Includes at least one high priority process im-
provement identified in the previous Retro-
spective meeting
- Belongs solely to the Development Team.
Only they can change it during a Sprint
Increment
- The sum of all Product Backlog Items com-
pleted during the Sprint and the value of In-
crements of all previous Sprints
- A step towards a vision or a goal
- Must be in usable condition regardless of
whether the Product Owner decides to release
it
Definition of “Done”
- When a Product Backlog Item or an Incre-
ment is described as “Done”, everyone must
understand what “Done” means
- The definition of “Done” is used to assess
when work is complete on the product Incre-
ment
- Guides the Development Team in knowing
how many Product Backlog Items it can se-
lect during a Sprint Planning
Definition of “Done” - Notes
- Multiple Scrum Teams working on the same
Product must mutually define the definition
of “Done”
- If the definition of “Done” is part of the con-
ventions, standards or guidelines of the devel-
opment organization, all Scrum Teams must
follow it as a minimum
- As Scrum Teams mature, it is expected that
their definitions of “Done” will expand to in-
clude more stringent criteria for higher quality
- A new Definition of “Done”, as used, may un-
cover work to be done in previously “Done”
Increments
Sprint Progress
- The Development Team tracks the total work
remaining in the Sprint Backlog at least every
Daily Scrum
- Helps evaluate the likelihood of achieving the
Sprint Goal
Release Progress
- The Product Owner tracks the total work re-
maining to reach a goal at least every Sprint
Review
- They compare this amount with work re-
maining at previous Sprint Reviews to assess
progress toward completing projected work
References
[1] Kent Beck, Mike Beedle, Arie Van Ben-
nekum, Alistair Cockburn, Ward Cunning-
ham, Martin Fowler, James Grenning, Jim
Highsmith, Andrew Hunt, Ron Jeffries,
et al. Manifesto for agile software devel-
opment. https://www.agilemanifesto.
org/, 2001.
Page 7 of 8
