When leading development teams, I see most of the wasted activities happen during the development phase. If work is not ready before development begins, there can be delays waiting for clarifications from the business. If acceptance criteria is not clearly defined before development begins, work can go on and on as the team tries to appease the customer. What your agile team needs is a clear definition of “Ready to Work” and a clear definition of “Done with Work”. Though definitions vary from team to team and organization to organization, it’s imperative that you do it. It’s also imperative the team writes the definitions, not someone in an ivory tower.As with all of our clients, my colleague Bob Payne and I stress the need to have a minimal agreement on both definitions before work is started. When defining both the entrance and exit criteria, all major parties within the team need to be involved, to lower risks that something will be missed.Below are examples of the definitions of ready and done. Notice that we consulted analysts, testers, and developers. For your team or organization, you may consult UX designers, DBAs, architects or others. Don’t make your definitions overly onerous. Just create something that is just good enough and go from there.
Example of a Definition of Ready
- Analyst – User story sufficiently defined and mapped from requirements
- Tester – Acceptance criteria developed
- Developer – User story is estimated and no known blocking dependencies exist within the sprint
Example of a Definition of Done
- Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection
- Tester – Test cases pass. All critical and high severity bugs fixed and other bugs identified and tracked
- Developer – Deployed to test environment and Code Review complete
So, what does your team require as part of your definition of ready or done? Do you have definitions?As a side note, if you’re preparing for the PMI-ACP exam, remember the team is responsible for the definition of done.
