Definition of Done/Ready

Done

Factors that could determine what Done looks like:

• Put broadly you are seeking an understanding of Acceptance Criteria from stakeholders, Product Leads and the team’s quality standards.
• You’re trying to gauge the minimum Acceptance Criteria for the above - what’s “must have”, what’s a “would like to have” and what’s for much later iterations? It’s all about finding out how quickly something valuable can be released.
• Who needs to see this work before it's released to customers?
• Has the quality of the work been checked? - this could range from reviews by colleagues, to completion of any relevant testing. This could also include reaching the correct standards around documentation (including that needed for audit trails).
• What “debt” has been agreed to be accepted? And is that documented? Sometimes when launching the minimum product, it can mean corners have had to be cut and these normally need to be cleaned up.
• Who needs to know the work has been completed? This can range from colleagues/teams you work alongside, to external stakeholders. There can be a long list of people to communicate to, and perhaps an order they need to be communicated in, so it’s good to have them identified so that nobody is missed.
• Is the end result behaving as you’d expect? You can quality assure during the development process, but once complete is everything OK or are any alarm bells ringing?
• Can you capture information (data) on whether you’ve achieved what you were expecting? How customers have reacted to the work?

Essentially, what is the agreed end product - what does it look like?

Taking that all into account, it can be complex! The important thing is not to make it too complicated. Defining Done should be a seamless process for teams and one that should be revisited frequently to make sure it’s working for the team and its stakeholders.

Ready

Definition of Ready compliments the Definition of Done. It’s great knowing what the end result looks like, however, is the work ready to start? Let’s look in greater detail at the sort of things to consider with the Definition of Ready:

• What - understanding exactly what it is that’s being asked. If it’s not clear, ask questions and make sure it is clear. Are there visual aids (pictures, videos, conceptual drawings) that can help explain what’s required, or currently happening that needs fixing?
• Why - what objective is this working towards? What’s the benefit going to be and for whom? What data backs up the “why” you’re doing this piece of work (including user research)? What’s pushing this towards the top of the priority list?
• How - is it clear how you’re going to do the work? It’s important teams assess their ability to deliver what’s being asked. If there are too many unknowns, call this out and take time to investigative work first. Some unknowns are OK, as long as they are expected to be easily ironed out while completing the work.
• Where - this could range from a selection of products to locations, groups of customers, in software engineering for example this could be desktop users, devices users (tablets and mobile) or both, or put simply, it could be a list of what/who is included or excluded.
• Who - are you dependant on anyone else before starting the work? Does other work need to be done before you can start yours (are you blocked from starting)? Is anyone doing other work that will impact you and, therefore, needs co-ordination to avoid duplication or clashes? Are there contact details for any third parties that need to support the work?

As development teams, working with stakeholders, it’s important to look at your definition of Done and Ready shortly after the team forms. Write everything down that you might need to think about in terms of understanding what Done looks like and if you’re ready to start. You’ll probably find a lot of areas can be grouped together to form headings. These headings can then be a checklist for anyone raising work to be completed.