Analyzing the Definitions of Ready and Done

Definitions must be very clear in a professional context.

Ready and Done are concepts with which most people think they're familiar from daily life, but there's a concrete risk of ambiguity if what is really meant isn't properly spelled out.

Think of how often you've heard someone say that something is done, but when you look more closely it isn't really done? A child stating they're done cleaning their room, but there are still a few socks under the bed. Or a student saying their science project is done, but they still need to put together the binder that contains all the information on the experiment. This can also happen in business contexts.

Agile software development is a way of developing software that focuses on producing small pieces of functionality at a quick pace and with frequent customer feedback. This is different from traditional development methods that could leave a team spending months working on a big application, only to learn that what they built wasn't really what the customer wanted.

Hence, definition of Ready (DoR) and of Done (DoD) must be agreed upon and be clear and exact – as well as related to the Agile framework. Ideally, they should be so clear that there's never any argument about them during execution.

This lesson will explain why a definition of Done is important and provide a model you can follow to prepare your own DoD.

Keep in mind that one team's DoD will be unique to that team's circumstances and type of work. This lesson presents examples, not strict instructions that every team must follow to the letter.

In this figure, how DoR, Acceptance Criteria, and DoD interrelate to one another is shown.

It should be noted that, unlike the definitions, the Acceptance Criteria are item-specific.

The team needs to have user stories in status Ready to be worked upon. The sprint velocity wouldn’t be good if the user stories weren’t Ready – that is, if they were to be converted to Ready during the sprint itself.

The project must have a steady number of User Stories with enough details so as to be processed.

This implies that some of the time needs to be reserved for getting User Stories from their original, often draft status, to the status of Ready – so that team's time can be put to proficient use.

This is an example definition of Ready – which can be customized for the local project terminology and Project Manager's expectations.

This is an example definition of Done. This can be customized. For example, you can be specific about the status of documents and visibility of objects in SAP Solution Manager or SAP Cloud ALM that you want to see.

This is another sample definition for the term Shippable.

Please review the first slide in this lesson again to ensure that you now have a good understanding of Ready, Done, and Shippable and the differences between these three statuses.