Few months ago, I was interviewing for an opportunity and the interviewer asked me ‘What is the difference between Done and Ready’ Now I had never thought about Done and Ready in a correlated way. Like they are similar type of concepts but with wholly different behavior and value add to the teams using them.
But that question made me think that and since then I have started paying a little more attention to these concepts and how my teams were leveraging them. Done and Ready are always used in context of a User Story and that is how I am going to talk about it.
Lets pick them one at the time
By its simplest definition, ‘Done’ is when a feature or functionality is ready to be used by the end user in real world. Agile teams use “Done” as sort of an exit criteria for a user story they are working on. Now the actual parameters to call something Done may differ from team to team but some are more commonly seen:
- All-green automated unit tests
- A sign off or UAT from your primary stakeholders
- All-green manual and automation tests
- All acceptance criteria satisfied
- etc etc
Its highly important for a team to have a concrete definition of Done because that’s the benchmark against which you measure the completeness and quality of your work. Done criteria usually remains same for each and every user story in a project however, the parameters can evolve as the team gets more mature. You can start with having above 5 checkpoints but over time you could also include things like automated functional tests, code quality checks or performance. Done helps you to quantify your development goals as you work towards achieving them.
Lets talk about Ready. Now I learnt about Ready only a few years ago. We were working on a huge redesign project and our backlog looked taller than Empire State! Yet whenever I sat with my team for sprint planning, we could actually pick very few stories up for development. Even with the high priority epics, we would always have something that would make that story not-just-ready enough to begin development. Often times it was incomplete UI mockups but other times it was also things like unresolved environmental dependencies or lack of required inbound data.
I hated that. Though it was not entirely my fault, yet it made me feel that I had not done a good enough job as a PO. So I spent hours sitting with UI designer, going over mockups or following up with other teams for status dependencies. Over the next couple of sprints, I was able to sense a pattern in challenges that made our stories not-so-ready for development. And in one of the retrospectives we decided on making a checklist of things that every story should have so development can start on time, as expected. That is how we came up with out ‘Ready’ criteria.
Since then I have been using the concept of Ready to its fullest. It tells me when the stories in my backlog are good to go in dev queue and when they are not. It helps our team be prepared and proactively resolve dependencies.
You can think of Ready as exactly opposite of Done. While Done is the Exit criteria for a user story to be out of development queue, Ready is its entry criteria to get in to the development queue. A user story is Ready when it has everything it needs to have in order to be picked up and developed. This could mean many things for your User stories:
- No unresolved questions, invalidated assumptions or ambiguities
- No outstanding dependencies on any other story or external factor such as environment readiness, data availability etc (Just doing this resolved most of our problems)
- Validated UI designs
- Comprehensive acceptance criteria
- Its testable, prioritized, estimated and is implementable within the sprint (Google INVEST mnemonic)
This could include few more things depending upon your project context and client expectations. Following a concrete definition of Ready is important to make sure your developers do not spend valuable dev time in back-n-forth, resolving ambiguities. Having all parameters in your Ready checklist ticked out is an assurance for you as a PO that you have done your part in making sure that your backlog is up to date and it makes sure the developers in your team get most time to do what they do best, i.e programme