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.

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,
• sensing patterns,
• listening closely to what is being said, and
• detecting differences between expected and real results.

There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency.

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. (INTEGRATION)

The Def of "Done" guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning

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.”

As Scrum Teams mature, 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.

DEFINITION INCREMENT
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.”
• The increment must be in useable condition regardless of whether the Product Owner decides to release it.

• An increment 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.

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.

...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.

...is dynamic, 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.

...have the attributes of a

• description,
• order,
• estimate (story points), and
• value.
  ... often include acceptance criteria and test descriptions that will prove its completeness when “Done.”

... 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.

... is the act of reviewing and revising items

• adding detail,
• estimates, and
• order (priority)
  to items 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.

The Scrum Team decides how and when refinement is done.

Refinement usually consumes no more than 10% of the capacity of the Development Team.

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.

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
Sprint time-box.

• 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.
  

However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

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.

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 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.
  

• 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.

• 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
  unnecessary, they are removed.

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.

• Items are written on cards (Scrum Board) visualize progress

DoD usually consists of

• Development processes
• Organizational processes
• Non-functional requirement
• quality criteria
• User acceptance criteria

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.

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