Scrum Artifacts Flashcards
Emergent, ordered list of what is needed to
improve the product
Product Backlog
Single source of work undertaken by the Scrum
Team.
Product Backlog
PO’s decisions are visible in the content and
ordering of the “…”
Product Backlog
While the Product Owner may delegate work,
ultimately, Product Owner remains accountable
Product Backlog
Attributes of PBI often vary with the domain of
work
Product Backlog
Multiple Scrum Teams working on the same
product should share the same Product Goal,
Product Backlog, and Product Owner
Product Backlog
Product Backlog items (PBIs) that can be Done
by the Scrum Team within one Sprint are
deemed ready for selection in a Sprint
Planning
Product Backlog
If a product exists, this (artifact) also exists, so
is never complete & is a living artifact
Product Backlog
PBIs can be updated at any time by the PO or
at the PO’s discretion (even outside of PBR)
Product Backlog
May be adapted (if appropriate) anytime, and
Sprint Review presents a “formal” opportunity
to adapt it
Product Backlog
Writing PBIs as User Stories (not part of
Scrum) is a common technique adopted by
teams new to Scrum. It is not the only way to
write a PBI. Mature teams use the most
appropriate and effective ways to create PBIs
(and this varies from domain to domain)
Product Backlog
Describes a future state of the product which
can serve as a target for the Scrum Team to
plan against.
Product Goal
Is in the Product Backlog
Product Goal
Is the long-term objective for the Scrum Team
Product Goal
Scrum Team must fulfill (or abandon) one
objective before taking on the next
Product Goal
Is the act of breaking down and further defining Product
Backlog Items into smaller more precise PBIs
product backlog refinement
Is an ongoing activity to add details, such as a
description, order, and size
product backlog refinement
includes developing and
explicitly communicating the Product Goal
product backlog refinement
includes creating and
clearly communicating Product Backlog items
product backlog refinement
includes ordering Product Backlog items
product backlog refinement
Ensures that the Product Backlog is transparent, visible
and understood
product backlog refinement
ensures that one PBI can reasonably be completed
within the Sprint time-box
product backlog refinement
Happens in the (current) Sprint to get PBIs ready for
(future) Sprints
product backlog refinement
PBIs deemed ready for selection in the (future) Sprint
Planning event acquire this degree of transparency after
refining activities
product backlog refinement
The Developers who will be doing the work are
responsible for the sizing of PBIs
product backlog refinement
General (old Scrum Guide) recommendation – not a rule
– usually consumes 10% of the time, may consume more
or less time depending on the domain of the product
product backlog refinement
The last opportunity to refine PBIs before they are taken
up in the current sprint is Sprint Planning Topic Two -
What can be Done this Sprint?
product backlog refinement
Sprint Planning will be long and boring if this is not done
diligently
product backlog refinement
During Sprint Planning, the Scrum Team might not have
clarity on the most valuable PBIs if this is not done
diligently
product backlog refinement
If this is not done diligently, PBIs may be too big to be
completed within the Sprint and may not deliver value
product backlog refinement
This optimizes the value of the work the Scrum Team
performs in the next sprint
product backlog refinement
PO may delegate all PBR activities (like writing PBIs,
ordering PBIs, etc.) to others, however the PO remains
accountable
product backlog refinement
Is composed of the Sprint Goal (why), the
set of Product Backlog items selected for
the Sprint (what), as well as an actionable
Is composed of the Sprint Goal (why), the
set of Product Backlog items selected for
the Sprint (what), as well as an actionable
plan for delivering the Increment (how)
sprint backlog
The plan (in Sprint Backlog) by and for the
Developers
sprint backlog
a highly visible, real-time
picture of the work that the Developers plan
to accomplish during the Sprint in order to
achieve the Sprint Goal
sprint backlog
created initially in during Sprint Planning
sprint backlog
updated throughout the Sprint as more is
learned (about what work needs to be done
to achieve the Sprint Goal)
sprint backlog
The most impactful improvements (from
retrospective) may be added to the “…” for the next Sprint
sprint backlog
During the Sprint, scope of work may be
clarified and re-negotiated between the PO
& Developers may be reflected here
sprint backlog
Is the single objective for the Sprint
sprint goal
Provides flexibility (to Developers) in terms
of the exact work needed to achieve it
sprint goal
creates coherence and focus, encouraging
the Scrum Team to work together rather
than on separate initiatives
sprint goal
Created during Sprint Planning and must be
finalized prior to the end of Sprint Planning
sprint goal
Does not change during the Sprint
sprint goal
As the Developers work during the Sprint,
they keep this in mind
sprint goal
The purpose of the Daily Scrum is to inspect
progress towards this and adapt
the Sprint Backlog as necessary, adjusting
the upcoming planned work
sprint goal
A Sprint could be cancelled (by the Product
Owner) if this becomes obsolete
sprint goal
The moment a Product Backlog item meets the Definition of Done, a “…” is born
Increment
Is a concrete stepping stone toward the Product Goal
Increment
Each “…” is additive to all prior “…” and thoroughly verified, ensuring that all “…” work together
Increment
In order to provide value, the “…” must be usable
Increment
Multiple “…” may be created within a Sprint
Increment
this may be delivered to stakeholders prior to the end of the Sprint
Increment
(The sum of the) “…” created during the Sprint is presented at the Sprint Review thus supporting empiricism
Increment
The entire Scrum Team is accountable for creating a valuable, useful “…“every Sprint
Increment
Work cannot be considered part of an “…” unless it meets the Definition of Done
Increment
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review
Increment
Product Owner’s decisions are visible through the inspectable “…” presented at the Sprint Review
Increment
The Scrum Master serves the Scrum Team in several ways, including helping the Scrum Team focus on creating high-value “…” that meet the Definition of Done
Increment
formal description of the state of the Increment when it meets the quality measures required for the product
DoD
During the Sprint, “…” ensures that quality (of the increment) does not decrease
DoD
Creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment
DoD
If “…” for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.
DoD
If it is not an organizational standard, the Scrum Team must create a “…” appropriate for the product
DoD
The Developers are required to conform to the “…”
DoD
If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same “…”
DoD
During Sprint Planning (Topic Three: How will the chosen work get done) the Developers plan the work necessary to create an Increment that meets the “…”
DoD
During Sprint retrospective, the “…” is inspected by the Scrum Team and adapted (improved) if necessary
DoD
