Definition of Done
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.
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.
I told my grandmother how you hpeled. She said, bake them a cake!
- 'Environment ready
- Development environment is ready with all third-party tools configured.
- Staging environment is ready.
- Continuous integration framework is in place. The build engine is configured to schedule hourly, nightly, and release builds.
- Desired build automation is in place. Why "desired"? Because there is no end to build automation :)
- Test data for the selected features has been created
- Design complete
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 written
Unit test cases have been written for the features to be developed.
- Documentation Ready
Documentation (Just enough or whatever the team agrees to) to support the sprint demo is ready
- Pre-Release builds
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:
- Compile and execute unit test cases (mandatory)
- Creation of cross reference of source code
- Execution of automated code reviews for verification of coding rules
- Code coverage reports are generated
- Detection of duplicate source code
- Dependency analysis and generation of design quality matrix (static analysis, cyclomatic complexity)
- Auto deployment in staging environment
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.
- Code Complete
Source code changes are done for all the features in the "to do" list." Source code has been commented appropriately.
- Unit testing is done
Unit test cases have been executed and are working successfully
- Code Refactoring
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.
- Code checkin
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.
- Code merging and tagging
Finalized source code has been merged with the main branch and tagged appropriately (merging and tagging guidelines are to be used)
- Automated Code reviews
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
Peer reviews are done. If pair programming is used, a separate peer review session might not be required.
- Code coverage is achieved
Code coverage records for each package are available and whatever the team has decided as the minimum benchmark is achieved.
- Project metrics are ready
Burndown chart has been updated regularly and is up to date.
- Release Build
- Build and packaging
- A Build (successful) is done using continuous integration framework. Change log report has been generated from Code Library and Release notes have been created. Deliverables have been moved to release area.
- Build deployment in staging environment
- Build deliverables are deployed in staging environment. If it is easy, this step should be automated.
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:
- Brainstorm – write down, one artifact per post-it note, all artifacts essential for delivering on a feature, iteration/sprint, and release
- Identify Non-Iteration/Sprint Artifacts – identify artifacts which can not currently be done every iteration/sprint
- 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
- 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:
- Creation of an impediments list that management can work on to support the delivery of the team
- Organizational awareness of problems stemming from organizational structure
- Team better understanding expectations of their delivery objectives
- Team awareness of other team member roles and their input to the delivery
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.
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.