Concepts

Definition of "Done"

Definition of Done guides the Development Department in knowing how many Product Backlog items it can select during a Sprint Planning. Each team creates its own DoD, and then the PO puts it in each Story. As Scrum Teams mature, their "DoD" will expand to include more strict criteria for higher quality. New definitions, as used, may uncover work to be done in previously "Done" increments.

Product Backlog

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. Requirements never stop changing, so a Product Backlog is a living artifact.

Sprint Backlog

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 highly visible, real-time picture of the work that the Development Department plans to accomplish during the Sprint, and it belongs solely to the Development Department.

Definition of “Ready”

Definition of Ready guides the Development Team in knowing if the item is ready to enter a Sprint Planning. The Development Team must grasp enough of Product Backlog item scope to be able to plan it into a Sprint and to frame some kind of commitment regarding its implementation so a Sprint Goal can be met. During Product Backlog refinement, detail, order, and estimates will be added or improved until the work on the backlog meets these criteria of "Ready". In effect, Product Backlog refinement helps to de-risk Sprint Planning.

These considerations are often summarized as the "INVEST criteria"

I (Independent). The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another BI or an external resource.

N (Negotiable). A good PBI should leave room for discussion regarding its optimal implementation.

V (Valuable). The value a PBI delivers to stakeholders should be clear.

E (Estimable). A PBI must have a size relative to other PBIs.

S (Small). PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.

T (Testable). Each PBI should have clear acceptance criteria that allow its satisfaction to be tested