Methodology Bits: Definition of Ready

The purpose of this document is to lay down an agreement between the PO and the developers regarding the requirements that the developers have in order to be able to work on the PBIs quickly and effectively.

What does it mean that a feature is ready for development? That the story…:

• … has a corresponding PBI, so that everyone can see the requirements
• … is in-line with the iteration goal, so that the produced waste is minimized during the iteration
• … has a user-story definition in the regular format, so that everyone sees what the PBI is about at a glance
  In order to [business value]
  As a [stakeholder]
  I want to [action to take]
• … is refined, so that its details are sufficiently understood by the development team, therefore it can make an informed decision as to whether it can complete the PBI.
• … has clear acceptance criteria, formalized as Acceptance Tests, and clear and testable performance criteria (when applicable), so that the requirements are conveyed clearly from the PO to the developers, and their satisfaction can be validated easily and automatically
• and the test data is validated, so that testing resembles the real usage
• … meets the INVEST  criteria:
• Independent: Self-contained, and has no dependencies upon other PBIs or external resources, so that there is no hidden work popping up mid-iteration
• Negotiable: Leaves room for discussion regarding its optimal implementation, so that developers have some freedom in the implementation
• Valuable: The values the PBI delivers to the stakeholders are clear, so that developers can focus on delivering value and won’t get lost in detail
• Estimable: Can be effectively compared to other PBIs, so that the PO can have a realistic estimate on what engineering effort the development might require
• Small: Can be effectively estimated and development must fit into a reasonable timeframe (less than an iteration), so that the feedback cycle can be kept short
• Testable: Has clear acceptance criteria which allows its satisfaction to be tested, so that the acceptance of the feature is not debatable
• … has its dependencies identified, and no external dependencies would block the PBI from being completed
• … has UX wireframes (where applicable), so that the developer has guidelines to go by and the PO has guidelines to verify the product
• … has the necessary UI items ready (where acceptable), so that the developer won’t have to wait for these to be delivered or use placeholders instead
• … is prioritized in relation to the other planned PBIs, so that the team can work on the most important features first
• … has a demo flow defined, so that the team member demoing the feature knows what to focus on
• … is not allocated or assigned to specific developers in advance, so that workload can be optimized during the iteration