Ready to implement

…getting closer and closer to actually implementing new ideas, new features, new products.

✣  ✣  ✣

Quality in, quality out. A smooth, sustainable and predictable product development cycle makes planning releases a breeze and both product owners and development teams shine.

A product backlog item is ready to implement 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 personas) 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); 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 product backlog items into ready to implement state. Spend this time during the sprint, not during the sprint planning meeting. 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.

Daarom:

Only allow items that are really ready to implement into a sprint.

✣  ✣  ✣

✣  ✣  ✣

---