Home
Done - Do you go beyond 'Done' and follow a 'Definition of Done'?
  v31.0 Posted at 17/05/2016 5:23 PM by Ulysses Maclaren
​Having a clear Definition of Done for your team is critical to your success and quality management in Scrum.

Every team is different, but all need to agree on which items are in their "Definition of Done".

There are 3 levels of "Done" in communication

Level 1

Level 2

  • Sending a "Done" email
  • Screenshots
  • Code

Level 3​

  • Sending a "Done" email
  • Recording a quick and dirty ​"Done Video"
  • Code (showing a full scenario e.g. a user story)​

Example of a level 3 "done"

Subject: RE: Manad - Coded UI Tests #2

> Create a new CodedUI test on your feedback form – search only to test the Telerik

Done

Coded UI Test passes in Visual Studio Figure – Coded UI Test passes in Visual Studio

Jing Video of the test running: http://screencast.com/t/ps17fqsV

Figure: Good example - The "done" shows a full scenario

There are 8 levels of "Done" in software quality

Start with these examples showing typical "Definitions of Done" from beginner teams to more mature teams:

Team - Level 1

  • The code compiles
  • All tasks are updated and closed
  • No high priority defects/bugs are on that user story

Team - Level 2

  • All of the above, plus
  • All unit tests passed
  • Greater than 1% code coverage (not earth shattering, but you need to start somewhere)

Team - Level 3

  • All of the above, plus
  • Successful build on the Build Server
  • Check in Policy - Changeset Comments Policy (all checkins must have a comment)
  • Check in Policy - Work Items (all checkins must be associated with a work item)
  • Code reviewed by one other team member (e.g. Checked by Bill)
  • Sending a Done email with screenshots
Check in policy Figure: Good example - Add check in policies to enforce your Definition of Done

Team - Level 4

  • All of the above, plus
  • All acceptance criteria have been met
  • All acceptance criteria have an associated test passing (aka. Automated functional testing with Web Tests (Selenium), Coded UI Tests, or Telerik Tests)
  • Sending a Done email (with video recording using Jing)
Acceptance Tests in MTM Figure: Good example - Acceptance Tests in MTM

​​​​

 


Figure: Good example - Done video showing the features worked on

Team - Level 5

  • All of the above, plus
  • Deployed to UAT (ideally using Continuous Deployment)
  • Complex code is documented (removing technical debt)
  • Product Owner acceptance

Team - Level 6

  • All of the above, plus
  • Multiple environments automatically tested using Lab Management
Lab management Figure: Good example - A tester Lab Management to create VMs for testing the application, then defines a test plan for that application with Test Case Management

Team - Level 7

  • All of the above, plus
  • Automated Load Testing
  • Continuous Deployment
Acceptance Tests in MTM Figure: Good example - Load testing involves multiple test agents running Web Performance Tests and pounding the application (simulating the behaviour of many simultaneous users)Team - Level 8 (Gold)
  • All of the above, plus
  • Deployed to Production
    Congratulations! You are frequently deploying to production. This is called “Continuous Delivery” and allows you to gather quick feedback from your end users.
     
    You might have everything deployed to production, but it might not yet be visible to the end user. This can be achieved by having “Feature toggles ” in place. The actual release of the functionality is a decision that the Product Owner and business takes.

More Information:​

Related rules

    Do you feel this rule needs an update?

    If you want to be notified when this rule is updated, please enter your email address:

    Comments:

    Note: Social Media login for Yotpo is not working in IE or Safari, please use Chrome. We are waiting for Yotpo to fix it.