Constitent defination of "Done"

Last post 04:12 am March 8, 2013
by Susanta Kar
4 replies
Author
Messages
06:27 am February 21, 2013

Hi everyone,

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.

Thanks

06:47 am February 21, 2013

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?

06:56 am February 21, 2013

Hi,
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

10:50 am February 21, 2013

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.

04:12 am March 8, 2013

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.