What does "done" mean to your team/organization?
Which definition do you prefer?
- The date or scope commitments (maybe even both!) were met, without too many (or too large of) issues, and so sufficiency is declared. Done is declared.
- The work increment met its success criteria, it "ships", and customers are happy. You're done!
On non-Agile projects, we've experienced things like "defect triage" to debate bug severity, particularly showstoppers, or de-scoping of "required" requirements because of an impending deadline. The product is only demonstrated to customers or senior managers near the end of the project, with often unhappy and even disastrous results.
Agile approaches should provide considerable flexibility to deliver value incrementally over the course of the project, but how does a team know the features are done? How does a team and the organization know that the incremental value is ready for the customers to see and use?
Teams need to know what "done" means at the individual story level, the theme level, and the release level, so they can always work toward being done at every level.
In this presentation, we will discuss:
- How to define acceptance criteria for each story
- The team working agreement (commonly called a Definition of Done) for technical excellence, with examples
- Guidelines for Story, Feature, and Release Done criteria
- "Done" traps to recognize and avoid
If your teams or organization struggle with getting consistently to "Done", this presentation is for you.
