Skip to main content

Constitent defination of "Done"

Last post 04:12 am March 8, 2013 by Susanta Kar
4 replies
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.


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

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.