Definition of Done

The Definition of Done is a key aspect of Agile done right. It is one of the critical aspects of Agile development and unless a team or organization has defined and understood what Done means for them, they will not be as successful as they could be.

Scott Downey, MySpace Agile Coach, has a Definition of Done that includes:

• Feature Complete
  
• Code Complete
  
• No Known Defects
  
• Approved by the Product Owner
  
• Production Ready

Based this list, here are some ideas I've compiled that attempts to describe what this looks like for an Agile team in general.

Feature Complete – The short definition of Feature Complete is that all the intended stories and associated tasks are completed that will enable the business value that was intended for that iteration. There may be some stability, performance, or bug fixing work yet to be done before being production ready. It would indicate that Stories and Conditions of Satisfaction are complete and understood, any analysis and necessary design is complete, environments have been setup for development and production, the code has been written and unit tested, functional test cases are written and understood. Necessary documentation for support staff and customer service has been completed. Deployment and risk mitigation understood.

Code Complete – Code is considered complete at the point where the development tasks for the sprint are completed. This would mean any necessary refactoring is done, TODO’s have been completed, code has been checked in, testing in integration has been completed, bugs fixed, and merged as necessary. It could include automated review, peer review, code coverage reviewed, and build ready to go.

No Known Defects – No defects that were created during the sprint are remaining. There may be unknown bugs, bugs in other parts of the software, bugs left from previous technical debt/legacy code, but the bugs created and found during the sprint have been addressed. It may also mean that any defects that are discovered in the section of code being worked on are also fixed, depending on the time necessary and approval from the Product Owner and the team. Pre-release builds/deploys have been created and validated.

There will be times when we purposely choose not to fix something (created during the sprint) however that should be the exception rather than the rule. Remember that not fixing a defect is creating technical debt that is highly likely going to cost us more if we have to come back to fix it later. The teams need to make sure that they aren’t over committing to stories to ensure that they have time to get what they commit to, triple done. This might reduce the velocity in the beginning, but as the team gets better at only biting off what they can chew (plus maybe a small stretch goal), they will become more highly performing and able to gain back that velocity and much more.

Approved by the Product Owner – The User Story conditions of satisfaction are completely met. The prototypes/mockups are reproduced to the satisfaction of the Product Owner. The Product Owner has received necessary approval from business stakeholders. Functionality has been demonstrated live to the Product Owner. Any other issues brought up by the Product Owner have a plan around them and the PO understands exactly what is going to production and what is not.

Production Ready – System is able to be deployed without adverse affects to the customer or other parts of the system. Functional, regression, performance, security, and acceptance testing (UAT) has been completed. All documentation and project information (backlog) has been updated and any incidents/issues not handled during the sprint are tracked in the appropriate system. Any necessary metrics have been updated. Any remaining closure steps have been completed (security audits, backups scheduled, training material ready as necessary, coordination with stakeholders and support staff ready/complete). Product Owner and stakeholders know the Deployment schedule.

What is your definition of done? How are you validating and measuring it? What decisions are you making because of it? <><

Reference:

• http://www.scrumalliance.org/articles/106-definition-of-done-a-reference
• http://blogs.myspace.com/index.cfm?fuseaction=blog.ListAll&friendId=319545476
• http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html