Ready to build

…scrum, about to pull in product backlog items into the sprint.

✣  ✣  ✣

{{{wish full}}}

• Downstream Definition of Ready equals the upstream Definition of Done.
• Definition of Ready means that any item pulled into the sprint.
• High quality definition of ready leads to high-quality work and speeds up velocity.

See below for a detailed explanation.

Therefore:

{{{therefore full}}}

✣  ✣  ✣

✣  ✣  ✣

Table below is based on Bill Wake's INVEST acronym.

Second column is the test designed to proof the validity of the first.

Check	Proof
immediately actionable	The development teams 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. To improve actionability, consider providing: UI sketches, wireframes, and mock ups; scenarios; design ‘comics’ and story boards.
independent	Any dependancies are identified and 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 sprint.
understanding	The development team explains the context, what, why (value creation) and for whom (persona) back to the product owner.
negotiable	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
valuable	The relative (business) value is clear and written on the item.
estimatable	The item's relative implementation effort expressed in story points is written on the item by the development team, using techniques like planning poker.
sized appropriately	The item's estimated implementation effort is 8 story points or less.
testable	Crystal clear acceptance criteria for both the product owner 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 user acceptance test. Popular tools like Cucumber can be used to express these criteria and facilitate automated testing practices. Other useful practices include giving examples of: use case processes; reports; queries; input forms; and inspectors.
demonstrable	Either the development team or product owner 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 validate earlier defined scenarios and their outcomes. A mercenary analyst can help verbalize the item in a concise, coherent and comprehensive way.

---