Definition of Done

From AgileBok.org

Share/Save/Bookmark
Jump to: navigation, search

Definition of done is one of the central concepts of Scrum process. Every iteration the team is supposed to release an increment of software that is fully done. Ideal Scrum team every iteration delivers software right to the customer hands, manages to arrange the trainings, print documentation and so on. Most of the real world teams, however, aim at somewhat smaller goals. What exactly is expected to be delivered by the iteration end depends on the team's definition of done.

Contents

Evolution of Done

There are different checklists and recommended definitions of done. However, there is no best definition that can be used by all the teams in the world. It is especially difficult to choose a reasonably wide definition during the transition phase from the traditional plan-driven methods, because in such situations the final testing phase of delivering software might easily take longer than half of the sprint.

There is no universal recipe for choosing the good definition, but as a rule of thumb it might be useful to adopt the very minimal possible definition from the beginning and then iteratively widen it. The point is to standardize what the team is actually able to reach and improve in the controlled manner without "adopting" standards the team is not actually able to follow. The minimal definition might be as loose as "Product Owner has to explicitly accept the delivered backlog items". Then it can be widened with e.g. "some automated tests included", "critical code code reviewed", "all the changes are developed in the test-driven mode", etc.

Building a definition of done

It is difficult to pin down a definition of done that suits all circumstances. The following definition is an attempt towards creating one common definition. This is not end of the road but a humble beginning. This, again, is intended to be high-level guidance that projects can tweak to suit their environment. In this attempt, different scenarios are considered to ensure necessary checkpoints are met.

Please be advised that this is intended just a reference and not as a done definition for a particular project. When it comes to agile methodologies, the KISS principle (Keep it Simple, Stupid) should be followed. Even seasoned practitioners would be scared of having such an exhaustive checklist. Therefore, use this just as a reference in building a done definition for your project.

A general definition of done can be spelled out in a "done thinking grid" (see Figure below). The grid components are defined and explained below.

link:http://www.agilebok.org/images/8/8e/Building_a_Definition_of_Done.png

I told my grandmother how you hpeled. She said, “bake them a cake!”

Column Two

Design analysis is complete as per the user story or theme. UML diagrams are either created or updated for the feature under development.

You might need to prototype various components to ensure that they work together. Wireframes and prototype have been created and approved by the respective stakeholders.

Unit test cases have been written for the features to be developed.

Documentation (Just enough or whatever the team agrees to) to support the sprint demo is ready

Pre release builds (hourly/nightly) have been happening and nightly build reports have been published on regular basis. The following could/should be part of pre-release builds:

It comes down to build automation; there is no end to what can be achieved from automated hourly, nightly builds. The team along with the product owner needs to decide on how much build automation is required.

Column Three

Source code changes are done for all the features in the "to do" list." Source code has been commented appropriately.

Unit test cases have been executed and are working successfully

Source code has been refactored to make it comprehensive, maintainable and, amenable to change.

A common mistake is to not keep refactoring in the definition of done. If not taken seriously, refactoring normally spills out to next sprint or, worse, is completely ignored.

Source code is checked in the code library with appropriate comments added.

If project is using tools which help in maintaining traceability between user stories and the respective source code, proper checkin guidelines are followed.

Finalized source code has been merged with the main branch and tagged appropriately (merging and tagging guidelines are to be used)

Column Four

Automated code review has been completed using the supported tools/technologies. Violations have been shared with the team and the team has resolved all discrepancies to adhere to the coding standard. (Automated code reviews should be hooked up with CI builds.)

Peer reviews are done. If pair programming is used, a separate peer review session might not be required.

Code coverage records for each package are available and whatever the team has decided as the minimum benchmark is achieved.

Burndown chart has been updated regularly and is up to date.

IJWTS wow! Why can't I think of tnhigs like that?

Exercising Definition of Done

Following is a list of steps that are used when coaching a team on their own Definition of Done:

  1. Brainstorm – write down, one artifact per post-it note, all artifacts essential for delivering on a feature, iteration/sprint, and release
  2. Identify Non-Iteration/Sprint Artifacts – identify artifacts which can not currently be done every iteration/sprint
  3. Capture Impediments – reflect on each artifact not currently done every iteration/sprint and identify the obstacle to it’s inclusion in an iteration/sprint deliverable
  4. Commitment – get a consensus on the Definition of Done; those items which are able to be done for a feature and iteration/sprint

The Definition of Done exercise can have many ramifications:

If you do not already have a Definition of Done or it has not been formally posted, try this exercise out. Building a Definition of Done in this manner will help your team get even better at their delivery.

Conclusion

Preparing a single definition of done that suits every situation is impossible. Each team should collaborate and come up with the definition that suits its unique environment.

Organizations that have just started with agile may find it difficult to reach a mature level immediately; therefore, they should take the steps, sprint-by-sprint, to improve their done definition. Feedback from retrospective meetings should also help to improve the definition of done.

Whether you use this grid or develop one of your own, remember that solid definition of done is essential to producing potentially shippable products at the end of each iteration.

References

  1. Building Definition of Done
  2. Agile Software Development
  3. Getting Agile
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox