SCRUM ARTIFACTS

Product Backlog

Ordered

Single source of requirements

Product Owner Role

The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

never complete.

The earliest development of it only lays out the initially known and best-understood requirements.

Evolves

Dynamic

Constantly Changes (to identify what the product needs to be appropriate, competitive, and useful).

As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

Product Backlog items have the attributes of a description, order, estimate and value.

Grows

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.

Refinement

the act of adding detail, estimates, and order to items in the Product Backlog

ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items

During Product Backlog refinement, items are reviewed and revised.

The Scrum Team decides how and when refinement is done.

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

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

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.

Top down - high value at top

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.

The Development Team is responsible for all estimates.

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.

Monitoring Progress Toward a Goal

At any point in time, the total work remaining to reach a goal can be summed

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.


Forecast Progress

empiricism

Sprint Backlog

Product Backlog items selected for the Sprint

plan for delivering the product Increment and realizing the Sprint Goal

Forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint.

As new work is required, the Development Team adds it to the Sprint Backlog.

When elements of the plan are deemed unnecessary, they are removed.

Only the Development Team can change its Sprint Backlog during a Sprint.

highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint,

Belongs solely to the Development Team.


Monitoring Sprint Progress

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.

Development Team can manage its progress.

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

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 actually release it.

cumulative flows / burn downs / burn-ups