Definition of DONE! 10 Point Checklist
by Kelly Waters, 26 July 2007 | Agile Estimating
A key principle of agile software development is “done means DONE!”
To be more specific, here’s a 10 point checklist of what constitutes ‘feature complete’…
- Code produced (all ‘to do’ items in code completed)
- Code commented, checked in and run against current version in source control
- Peer reviewed (or produced with pair programming) and meeting development standards
- Builds without errors
- Unit tests written and passing
- Deployed to system test environment and passed system tests
- Passed UAT (User Acceptance Testing) and signed off as meeting requirements
- Any build/deployment/configuration changes implemented/documented/communicated
- Relevant documentation/diagrams produced and/or updated
- Remaining hours for task set to zero and task closed
Kelly.
See also:
Agile Principle #7: done means DONE!
Agile Principle #6: Fast but not so furious!
10 Key Principles of Agile Software Development
Photo by saital
Good sample criteria. However, for organizations just starting to apply agile methods it might be impossible to reach immediately.
To me it is more important to get any common definition of done even if it is “Product Owner has to agree that the feature is done” and then bit by bit improve the definition until it includes delivery to the end user.
I do not think that you can pin down a def. of done that suits everyone. The team must decide together what done means to them. And write it down.
Thanks for your list. We used it for our team as an example. But like the other guys said every team has to find its own definition of done, fitting the specific context.
Here’s ours:
SPRINT CHECKS AND BALANCES
Overview
• Sprint Checks and Balances are the procedures and processes by which authoritative decisions and mandates, translate into workflow, are fulfilled, measured, and then identified as either failures or successes, based upon whether the outcome reflects the income.
Checks
• Acceptance criteria is to be clearly defined by stakeholders during the sprint planning session for all deliverables before any estimating can start.
• Sprint Planning Session Must Be “Signed On” by a Stakeholder otherwise the plan is not authorised and will not be implemented. No Sign-On, No Sprint-Start.
• The Sprint is not complete until a Stakeholder explicitly Signs-Off the Demo (note: what does Sign-Off mean and what does it imply?).
• A new Sprint Planning Session is not to commence unless there is a Retrospective of the Previous Sprint “in which a stakeholder signs-off the retrospective”.
Balances
• This Definition of Done Document is to be revised each Sprint and the new version signed into during the next Sprint Planning Meeting.
PEER REVIEWED
Overview
‘Peer Review’ is to consist of two components:
1. Code Review, and
2. Process Review.
Code Review
• An informal review of code, and where applicable, UI, reviewed by someone in the team who is other than the person who wrote the code (or UI).
• A 2 hour side-by-side reviewee/reviewer collaboration in which the person doing the review:
o Adapts to the context of the person being reviewed.
o Writes a 250 word snapshot of how the session went.
o Adds the Word Picture to the Jira Task Description that was raised at the start of the Sprint, for the conduct of the review.
• The Code Review should only cover work done on the current Sprint.
Process Review
• An informal review of the process and processes undertaken, reviewed by someone in the team who is other than the person who wrote the code (or UI) that are part of the processes being examined.
• Conducted concurrently with the Code Review.
• Process Review should cover the following processes:
o Build
o Unit Testing
o Documentation
o Design
o Jira Task Tickets satisfactorily reflecting work done.
• The Process Review should only cover work done on the current Sprint.
CODE COVERAGE > 80%
Overview
• The Term Code Coverage in the context of Sprint Planning and Administration, implies ‘The Amount of Code that is covered by Unit Tests’, and this raises two questions:
o By what method are Unit Tests themselves created?
o With what measure is it determined that the Unit Tests that have been created, do indeed have a coverage of greater than a certain percentage of the codebase?
Methods by which Code is unit tested, will relate to the technology.
Measurement of how much code that the methods cover, will relate to the software that is chosen to examine the coverage and output a coverage statistic.
Method
• Silverlight Technology. The present Unit Testing methodology is to be based upon Moq (see Reference D), in which all of the View Models are to be mocked and tested. It is envisaged that (subject to choosing a Code Coverage Measurement Tool) that the testing of all View Models will cover 80% of the codebase.
• Middle Tier. All Classes are to be Unit Tested and that all unit Testing will cover 80% of the codebase.
Measurement
• As at the time of writing, a Code Coverage Testing Tool is still being chosen.
• Code coverage is to apply the 80/20 rule and maximise coverage on high-risk, high-value areas, and not try to cover the last costly 20% which might return very little value.
AUTOMATED DEPLOYMENT
Overview
• Automated Deployment is the automation of processes that identifies a new codebase version that has been compiled, to be deployed.
• In the present environment, Hudson (The Open Source Codename Jenkins Version, see Reference E) is core to the automated deployment process.
Implementation
• To be advised.
DESIGN AGREED
Overview
• The term “Design Agreed” implies that an agreement has been made as to the extent of the design, as well as the limitations, which at the granular level will include an agreed feature by feature list of features that are agreed as integral to the function of the design.
Design
• A feature by feature list of UI features that are demonstrable
• A feature by feature list of non-UI design artefacts
Agreed
• The UI Feature List should be:
o Based upon requirements collected by the Stakeholder and presented to EventGeneration.
o Signed On to a Sprint by the Stakeholder/s during a Sprint Planning Meeting.
o Signed Off by the Stakeholder/s after a demonstration of the features at the completion of the Sprint.
• The Non-UI Design Artefacts should be:
o Based upon requirements collected by the Stakeholder/s and presented to EventGeneration.
o Artefacts presented to EventGeneration by the Stakeholder/s should take the form of a logical and/or architecture diagram of the solution.
o An Artefact Definition of Implementation statement should be supplied with any such logical and/or architecture diagram so that specific boundaries are definitively agreed upon at the start of each Sprint.
o Signed On to a Sprint by the Stakeholder/s during a Sprint Planning Meeting.
o Signed Off by the Stakeholder/s after a demonstration of the features at the completion of the Sprint.
DEPLOYED
Overview
• During the development process, but within the scope of Sprint by Sprint planning, the term Deployed means “a software build deployed to a server so that it can be demonstrated to the Stakeholders to signify that the work undertaken at the start of the Sprint, was successfully completed during the Sprint”.
Deployment
• Deployment is to be to the Development Server
• Deployed no later than 4 hours before the End-Of-Sprint Demonstration is scheduled to take place.
• Deployed in a condition that is demonstrable (see following section).
DEMONSTRABLE
Overview
• In the context of the Sprint Planning Meeting, the term Demonstrable means that a software build is capable of being demonstrated to Stakeholders in a context that proves to them that Previously Agreed Value has been added since the previous Sprint.
• ‘Capable’ of being demonstrated, means that the build being demonstrated to Stakeholders would in fact demonstrate all of the Design Agreed features that were signed on to the Sprint, and subject to sign-off after the demonstration at the end of the Sprint (see the section Design Agreed).
Demonstration Capability
• A build that is said to be ‘demonstrable’ must be:
o Capable of being Deployed (see the section called Deployed) without modification to the code;
o Expose the feature by feature list of UI features that are identified under the Design Agreed section.
o Expose the feature by feature list of non-UI design artefacts that are identified under the Design Agreed section.
o All of the Design Agreed Features must have the capability of being signed-off by the Stakeholder/s.
OPERATIONALLY SUPPORTABLE
Overview
• For software to be Operationally Supportable, it must be supportable by operations staff, and this means that it must be monitorable, loggable, and documented.
• These functions must be supported in two contexts:
o Network – for example, where a database is accessed, a monitor that checks whether the database is running and accessible.
o Clientside (Desktop) – for example, Silverlight logging to Isolated Storage to fulfil traditional Desktop logging scenarios.
Monitorable
• A Diagnostics Page that is viewable by Operations Staff to fulfil the monitorable function:
o A Description of what the page shows.
o OK and Failure Counters for the various system components
Diagnostics UI
Diagnostics Middle-Tier
Have the appropriate interfaces:
• Diagnostics Logging Interface
• Other Interfaces as identified
Documented
• Diagnostic Pages should be documented so that Operations Staff easily understand when the system is operating normally, as well as understanding what behaviour is not normal.
• A Trouble-Shooting Guide should be gradually developed and added to each Sprint to incorporate the latest addition of features.
• A Problem-Symptom-Action Guide should be incorporated into the Trouble Shooting Guide so that when the Diagnostics Page identifies a problem, that the response to it by Operations Staff can be easily determined.
UNIT TESTED
Overview
• In Unit Testing, a unit is the smallest testable part of an application, and this shall be done concurrently with development, and have Code Coverage as specified in the Code Coverage section. In EventGeneration, this has three contexts:
• Silverlight (Clientside),
• Middle-Tier (Serverside).
• Measurement.
Silverlight
• Each View Model will have a mirror test class in an assembly that is Namespace.Tests of the assembly that the actual ViewModel is in.
Middle-Tier
• Every class is to be Unit Tested.
Measurement
• Once software is built, all unit tests should pass, we should have a page that demonstrates that the tests have passed.
INTEGRATION TESTED
Overview
• Integration testing is the integration of software into the existing domain
Testing
• The QA team have executed all automated testing frameworks designed to test the new software’s integration into the existing domain, integration testing should pass and testing team should be able to show artefacts of execution and passing of tests
o test report
o web page with green lights
o (etc => needs to be expanded)
DOCUMENTED
Overview
• Documentation covers everything from commenting individual classes and methods, through User Documentation, to Operation Staff Diagnostics Documentation.
User Guide
• A User Guide shall be progressively created
o The new features that are demonstrated at the end of a Sprint shall be added to the User Guide
o The User Guide should be signed off by the Stakeholders at the completion of each Sprint
o Additions to the User Guide should include:
Additions to the UI.
Additions beyond the UI.
Updates to the Architecture Diagram (if necessary).
Updates to Logical and Dataflow diagrams.
• Documentation should be maintained for end-user guides on UI-based systems or integration and programmer guides for API and SDK types of products; Class Diagrams should be updated, and if possible, automated.
• Code should be easy enough to read and understand without the need of extra code-level documentation, however in some cases code-level documentation will be necessary when dealing with complex business logic.
AUTOMATED BUILD
Overview
• Automated Build is the precursor to Automated Deployment (see above) and is the process of building new versions of the same codebase, once a new version becomes available.
Implementation
• Hudson is to be configured to construct MSI’s for delivery to the DevOps Team, in which case the DevOps Team is to identify how it is to be delivered, where it is to be delivered, and via what interface.
• Hudson is to have environment specific switches so that no manual intervention is required with regards the configuration files.
• The automated build architecture is to be upwardly scalable so that automated deployment will be to the appropriate Dev / Demo server after the code is built and automatically unit tested.
• In this environment, a new Code-Commit to the Subversion Repository represents a new build opportunity, and Hudon (Jenkins) would typically monitor the Subversion Repository, and subject to certain predefined parameters, automatically build and deploy certain commits to Subversion that satisfied certain, predefined parameters.
• All Code check-ins to Subversion will automatically build in Hudson.
• It shall be determinable that builds are:
o Automated
o Successful
VERSIONING
Overview
• Versioning is the process of defining the incremental significance of new builds, typically in the format (major release).(minor release).(build number).(RC/alpha/beta etc)
Implementation
• As part of the automated build process we should have an automated versioning scheme for each component we create an msi for.
• A format shall be decided that at a minimum it should have (major release).(minor release).(build number).(RC/alpha/beta etc)
• The version should be retrofitted back to Subversion by being added to a subversion tag.