SCRUM Transparency & the 3 Artefacts (PRODUCT BACKLOG (A PRODUCT…
the 3 Artefacts
SCRUM'S ARTIFACTS represent
work or value to
provide transparency and opportunities for inspection and adaptation.
Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints (integrated).
At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”
must be in useable condition regardless of whether the Product Owner decides to release it.
is a body of inspectable, done work that supports empiricism at the end of the Sprint.
The increment is
a step toward a vision or goal
Scrum relies on transparency.
Decisions to optimize value and control risk are made based on the perceived state of the artifacts.
To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
ROLE OF SCRUM MASTER
The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent.
THE SCRUM MASTERS JOB IS
to work with the Scrum Team and the organization to increase the transparency of the artifacts.
This work usually involves learning, convincing, and change.
Transparency doesn’t occur overnight, but is a path.
A Scrum Master can detect incomplete transparency by
inspecting the artifacts,
listening closely to what is being said, and
detecting differences between expected and real results.
practices for coping with incomplete transparency
; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency.
DEFINITION OF "DONE"
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.
Although this may vary significantly per Scrum Team,
members must have a SHARED UNDERSTANDING of what it means for work to be complete, to ensure transparency.
This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
THE PURPOSE OF EACH SPRINT is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
The Def of "Done" guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
COLLABORATION WITH OTHER TEAMS & COMPANY GUIDELINES
IF the definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization
, all Scrum Teams must follow it as a minimum.
IF "Done" for an increment is NOT a convention of the development organization
, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product.
If there are
multiple Scrum Teams working on the system or product release
, the Development Teams on all the Scrum Teams must mutually define the definition of “Done.”
DoD is not in ownership of the Scrum team, also the customers and stakeholders have a say via the PO, apart from the guidelines of the Development Organization.
As Scrum Teams
, it is expected that their
definitions of “Done” will expand to include more stringent criteria for higher quality and robustness.
New definitions, as used, may uncover work to be done in previously “Done” increments.
Any one product or system should have a definition of “Done” that is a standard for any work done on it.
DoD usually consists of
User acceptance criteria
MONITORING PROGRESS TOWARDS GOALS
At any point in time,
the total work remaining to
reach a goal can be summed.
The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews
TO ASSESS PROGRESS TOWARD COMPLETING PROJECTED WORK BY THE DESIRED TIME FOR THE GOAL.
This information is made transparent to all stakeholders and users, they have access to the product backlog.
have been used to forecast progress, like...
These PROJECTIVE PRACTICES have proven useful. However, these do not replace the importance of empiricism.
In complex environments, what will happen is unknown.
Only what has already happened may be used for forward-looking decision-making.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the SINGLE SOURCE OF REQUIREMENTS for any changes to be made to the product.
The PRODUCT OWNER IS RESPONSIBLE
for the Product Backlog, including its content, availability, and ordering. Can delegate work on it, but stays responsible.
The PO's decisions regarding the ProdBL are indesputable and need to be accepted and respected by the Scrum team as well as the management
A PRODUCT BACKLOG...
is never complete
, The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves.
As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list.
, it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlogalso exists.
lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
PO is responsible, yet can assign to DT.
is a living artifact and is allowed to change and grow
, as Requirements never stop changing. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
THE PB IS THE
SINGLE SOURCE OF REQUIREMENTS
... there can only be one (Highlander)
Multiple Scrum Teams often work together on the same product and for all teams there will only be one PB. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.
Any DevTeam can only do work from the PB, there are no other sources.
Product Backlog ITEMS
...have the attributes of a
estimate (story points)
... often include acceptance criteria and test descriptions that will prove its completeness when “Done.”
ORDERED IN PRIORITY: HIGHTEST VALUE ITEMS FIRST AT ANY TIME!
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail.
REFINEMENT / GROOMING MEETINGS
Product Backlog items that will occupy the Development Team for the upcoming Sprint are REFINED so that any one item can reasonably be “Done” within the
Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “READY” for selection in a Sprint Planning.
Product Backlog items usually acquire this degree of transparency through the above described refining activities.
Short, simple description of a feature (requirement) on a karteikarte
Usually told by/from the perspective of a user/customer
type of user
, so that
Priority: Highest value first at any time
kann Akzeptanzkriterien festlegen für feature
Invest Modell (ob eine user story gut geschrieben ist.
User stories sollten sein
small enough (for 1 sprint)
... is the act of reviewing and revising items
to items in the Product Backlog.
This is an ongoing, continuous process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.
The Scrum Team decides how and when refinement is done.
Refinement usually consumes no more than 10% of the capacity of the Development Team.
However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
The Development Team is responsible for all estimates.
The Product Owner may influence the
Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
DEFINITION OF READY
Checklist if an Backlog item is refined enough so it can be executed during a sprint.
not mandatory, not part of the Scrum framework
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.
The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.
By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint,
and it belongs solely to the Development Team.
Only the Development Team can change
its Sprint Backlog during a Sprint.
The whole DevTeam owns the SpBL
As new work is required, the DevTeam
adds it to
the Sprint Backlog.
As work is performed or completed,
the estimated remaining work is updated.
When elements of the plan are deemed
they are removed.
Items are written on cards (Scrum Board) visualize progress
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.
The Sprint Backlog is
a forecast by the DevTeam about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal.
To ensure continuous improvement, the SPBL
includes at least one high priority process improvement
identified in the previous Retrospective meeting.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.
The Sprint Backlog
belongs to DevTeam
UStories get decomposed into takss of max 1 day (in hours)
The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint.
This EMERGENCE occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.