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.
A product backlog item is ready to build when:
- it brings the product closer to the product goal;
- the product owner:
- can prioritize it;
- has quantified its value;
- knows how to demo it (prepare the demo appropriately before the sprint review meeting);
- the value of its outcome for the user (or vibrant persona) is clear, detailing how it fulfills a need, goal or desire;
- it is detailed appropriately:
- as an enabling disclosure; and/or
- a page from the user manual, written by a mercenary analyst;
- crystal clear acceptance criteria are distilled (e.g. expressed in a domain specific language like Cucumber); these go hand in hand with the user manual section;
- non-functional criteria are clear;
- it is small enough, e.g. no larger than 8 story points;
- the development team:
- says “Ah, we get it!”;
- knows their implementation strategy, direction and conceptual design;
- can estimate its implementation cost in story points and have done so;
Spend about 10% of the sprint time on grooming the items into ready to build state. Spend this time during the sprint, not during the planning session. Make it you goal to reduce the sprint planning meeting to a mere reconfirmation of the product backlog that emerged during the sprint's grooming sessions.
Only allow ready to implement items into the sprint backlog, or risk to be bitten by debate, technical debt, cutting corners, and high pressure. Aim for quality in, quality out.
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:
|
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:
|
valuable | The relative (business) value is clear and written on the item. |
estimable | 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:
Popular tools like Cucumber can be used to express these criteria and facilitate automated testing practices. Other useful practices include giving examples of:
|
demonstrable | Either the development team or product owner or both can demonstrate the item when implemented.
Defining and scripting the demonstration helps to:
A mercenary analyst can help verbalize the item in a concise, coherent and comprehensive way. |