Constitent defination of "Done"
Can you please help me understanding what is the consistent definication of "Done" across sprints. As i am new can you please give me an example to understand clearly.
It can be a list of activities which each PBI or User story should pass e.g.
1. Code checked-in into a repository
2. Build deployed on an integrated environment
3. All guidelines (design, coding, DB etc..) has been followed
4. The application has been tested on all supported browsers (for web based)
5. Test cases been written, reviewed and executed on the integration environment
6. and finally, it has been approved by PO
Does it make sense?
the Definition of “Done” is the statement of what work needs to be completed to get to the "Ready to Ship" state.
* An auditable checklist the Development Team uses to know when they are complete developing each PBI
* The definition should be clearly understood by the Product Owner
* for the whole product, not just one team
This spells out what work needs to be done on a PBI to get it in to a state where it is potentially shippable. This needs to be clear to the Product Owner and the Team to promote transparency.
Your Definition of Done should be reviewed every Sprint Retrospective to see how it can be improved. You need to start at a level where you can get work finished in a Sprint, and gradually make it better. Remember that if your PBI does not meet your DoD, it can not be shown at the Sprint Review.
An Example Definition of Done:
All tests pass
All code compiles
All builds automated
Coding Standards followed
Well known design Principles Used
All code written using TDD
An installer is created
Sanjay and Simon have given good advice. I'd just add a couple of points:
1) A DoD should take a PBI to the point that it is release ready, i.e. all PBI's for a sprint must be potentially releasable into live when they are "Done". A DoD of that quality will allow business value to be delivered early and continually. It's a tall order for many teams, especially when starting an agile transition. This is why a DoD needs to be reviewed every sprint. Your team need to explore ways by which they can get closer to the "potentially releasable" goal.
2) Don't forget to look at NFR's (Non Functional Requirements) for criteria that should be added to a DoD checklist.
Across Sprints DoD should be the common set of items that need to be accomplished. It should have all phases general review/verification outcomes and validations results. NFR may not be applicable across sprints.
Prior folks have already marked individual entries.