Ready to implement

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

✣  ✣  ✣

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

ready to implement is designed to stop time being wasted when it’s discovered that user stores are missing important pieces of information that means they can’t be started or completed.

A product backlog item or user story that is ready to implement gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, ready to implement can improve the flow and stability in a sprint.

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, articulated in the format ‘As a role I want to reach some goal so that value or benefit’.; the part starting with “to…” can be put right into the user manual;
• 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;
  • follows the INVEST model;
    • no external dependancies block the item being completed;
• non-functional criteria are clear;
• it is small enough:
  • a handful of product backlog items can be completed in a single sprint
  • an item is 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;

ready to implement removes a major impediment:

• Removed disruptions and waste caused by issues being clarified with customer or other.
• It’s about focus, commitment and how to share knowledge.
• Easy to address when identified.

Make features ready to implement before they are ready to ship:

• do not allow a feature to be included in sprint unless it is ready to implement;
• simple concept, depends on discipline and creates stability in sprint;
• prepare product backlog with at least same speed as sprints;

product owner tasks are not part of sprint plan:

• clarification is a disruptive activity by nature;
• make clear arrangements for how product owner activities are supported by development team;

development team both deliver sprints and support product owner:

• balance is achieved by first ensuring that features and user stories are prepared sufficiently using these objectives
  • a feature can be implemented by development team in one sprint (< 600h);
  • a user story can be implemented by 1–2 people within 1–2 days (< 50h)
• development team proactively participated in workshops preparing sprint planning meeting

Systematically remove impediments:

• sprint retrospective at the core;
• measure and analyze data, e.g. fix-time for broken builds or flow.

Lead developers typically assist on multiple stories.

Spend about 10% of the sprint time on grooming the product backlog items into ready to implement state. Spend this time parallel to 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.

sprint planning meetings that spiral out of control and lively debates on particular sprint backlog items that have already been taken into the sprint are bad smells indicating the team is working on unready to implement items.

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. Spend about 10% of the sprint time on grooming the product backlog items into ready to implement state.

✣  ✣  ✣

✣  ✣  ✣

Sources:

• http://www.boost.co.nz/blog/agile/definition-of-ready/
• http://systemagility.com/2011/05/17/definition-of-ready/
• http://agile2009.org/files/session_pdfs/Going%20from%20Good%20to%20Great%20with%20Scrum%20Session.PDF

---