Scrum Beginnings (Part 8): The Definition of Done

Man writing note on paper

Before your team begins working as an official Scrum team, you will want to make sure you have come to an agreement on what the definition of “done” means before having a user story accepted. This is a very important task that needs to be done so that it is 100% clear to the developers and testers what is required of them during a typical sprint. Along with the definition of “ready”, you will be developing a great foundation for fantastic stories.

As I mentioned before, whether you think the responsibility to arrange this meeting falls on the Product Owner or not, I would go ahead and set it up in case the Product Owner is new and not as experienced. I recently helped facilitate this meeting for one of the teams I work with. Here is an example of what we came up with.

Definition of Done Example:

  1. Have the test plans/cases been created?
  2. Have the test cases been reviewed by the PO, QA and possibly the team tech lead?
  3. Have the unit tests been added and are they passing?
  4. Are the Black box/Integration tests passing at the component level? System level?
  5. Have the Pull requests been reviewed by at least two developers?
  6. Have the test cases been executed?
  7. Have any known defects been documented and/or addressed?
  8. Have all manual test cases been added to Q-Test (Test Management Solution)?
  9. Is there any necessary Help or User Documentation that needs to be addressed?
  10. Does the story meet all the acceptance criteria in the details?

This is a prime example of a solid “definition of done” for a software development team. If you do not work in a software related field, have no fear! The point of the agreement is to come up with a rock solid document that will leave no doubt in the minds of your team about what is necessary to have a user story considered complete. At this point, you would be able to add these agreements to a user story when needed. You may not need every bullet point for every story, but it will help guide you as you task out your user stories. For example:

Task Template Example:

User Story #1 – Create Widget A

Task 1: Spike: Investigate necessary technology

Task 2: Development

Task 3: Create Test Plan

Task 4: Write Manual Test Case

Task 5: Test Case Review

Task 6: Create Pull Request

Task 7: QA

Task 8: Demo to the PO

 

Conclusion:

So before you have your first Sprint planning, get together as a team and work out what is necessary to satisfy the Product Owner’s vision of what the DOD is! This will ensure that the details don’t get lost in the shuffle as you begin developing your new features.

Advertisements