When leading development teams, I see most of the wasted activities happen during the development phase. If work is not ready, before the team begins development, there can be delays waiting for clarifications from the business. If acceptance criteria is not clearly defined, before the team begins development, work can go on and on trying to appease the customer. What your 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, 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 or 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.
Image Sources: Pictofigo