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
  

Agile Defect Fixing

I just read a posting on AgileBuddy about accounting for bugs in an Agile world. The post talked about accounting for bugs, team capacity, and whether bugs should count in team velocity.

It is very clear to me, both from the literature and from experience, that you should account for defect work done in the sprint. You must account for all the work done, otherwise you set false expectations for your business partners, for other stakeholders, and for the team itself (creating a tendency to over task and over commit). There is more than one kind of defect however and they don't all need to be treated the same.

Defects found during the sprint that are a result of coding done during the sprint (sprint defects) should be part of your normal code/fix work. We don't track hours or points for these because they are part of the original story point/task hour plan. This does mean that you have to think about that during sprint planning. We should be planning on code quality, requirements clarity, and the things that create less defects too of course.

Defects found that are not a result of the sprint or that are found during the sprint and the team/PO chooses not to fix them (based on time and priority), are put into the backlog for future sprints. These need to be prioritized by the PO and estimated just like any other backlog item.

If a defect is planned to be fixed during the sprint, we consider it part of the sprint backlog and it gets counted in the velocity. We typically add a "bug" story that gets x number of story point assigned to it, then we add defect tasks that approximate the story point estimation. This allows us to keep working on defects that are found at other times or by other stakeholders/customers.
I don't think that punishing the team by not including their defect work in the sprint is productive. We have a lot of legacy code that the teams are not the originators on and to make them accountable for previous years mistakes (before Agile) doesn't make sense. I do however believe it's important to keep the team accountable to their commitment of story points and to completing the sprint defect free. The basic point is that the team working on an issue, isn't necessarily the one that created it (which can cause mixed feelings and eventually a lack of productivity).

Agile and QA is an evolving process for us, but as we move toward more automation and more consistency in our Agile implementation, we're starting to see better and better results. There is much more to say about defect management in Agile to be sure, stay tuned.