View source for Ready to build

{{Oyster
|stage=Germ
|theme=Agile, Scrum
|context={{scrum}}, about to pull in {{pbi}}s into the {{p|sprint}}.
|wish in a single line=Full focus of transforming wishes into reality.
|therefore in a single line=Make sure any item is fully ready to implement before you start working on it.
|wish=Full focus of transforming wishes into reality.
|background=
Downstream Definition of Ready equals the upstream Definition of Done.

Definition of Ready means that any item pulled into the {{p|sprint}}:

See below for a detailed explanation.
|therefore=Make sure any item is fully ready to implement before you start working on it.
}}


{|rules="rows"
|-
!align="left" width="20%"|Check
!align="left"|Proof
|-
|valign="top"|'''immediately actionable'''
|valign="top"|The {{dt}}s have no no known questions regarding the what, why and for whom of the item and  can immediately start implementing the item, working on it until it is done, completing it until it meets all criteria that allow it to be pulled into the next station;
|-
|valign="top"|'''independent'''
|valign="top"|The dependency count is less than three, meaning that the item is relatively independent and does not pull a lot of other items into the {{p|sprint}}.
|-
|valign="top"|'''understanding'''
|valign="top"|The {{dt}} explains the context, what, why (value creation) and for whom (persona) back to the {{po}}.
|-
|valign="top"|'''negotiable'''
|valign="top"|The item is clear on the what, yet still leaves room for:
*how it will be implemented, meeting or exceeding the non-functional requirements and within the technological and architectural guidelines; and
*nudging details—functional, behavioral, technical, or otherwise that would benefit its use or implementation
|-
|valign="top"|'''valuable'''
|valign="top"|The relative (business) value is clear and written on the item.
|-
|valign="top"|'''estimatable'''
|valign="top"|The item's relative implementation effort expressed in {{sp}}s is written on the item by the {{dt}}, using techniques like {{p|planning poker}}.
|-
|valign="top"|'''sized appropriately'''
|valign="top"|The item's estimated implementation effort is 8 {{sp}}s or less.
|-
|valign="top"|'''testable'''
|valign="top"|Crystal clear acceptance criteria for both the {{po}} and operations are associated with the item, probably written on the back of the item or documented in an automated test harness.

Acceptance criteria help to:
*set scope; and
*define when an item is done and ready for demo and {{p|user acceptance test}}.

Popular tools like Cucumber can be used to express these criteria and facilitate automated testing practices.
|-
|valign="top"|'''demonstrable'''
|valign="top"|Either the {{dt}} or {{po}} or both can demonstrate the item when implemented.

Defining and scripting the demonstration helps to:
*set scope;
*think through the many aspects of its use;
*find both happy and exceptional paths through the item's use; and
*valide earlier defined scenarios and their outcomes.
|}

{{Source
|author={{mvs}}
|coder={{mvs}}
}}