tags:

views:

2362

answers:

8

While Scrum is easy in theory and hard in practice, I wanted to hear your definition of Done; i.e. what are the gates (unit test, code coverage > 80%, code reviews, load tests, perf.test, functional tests, etc.) your product has to go through before you can label the product "Done"

+1  A: 

Listen to this podcast: What is Done? - A Conversation with Scrum Co-Creator Ken Schwaber.

Kasprzol
Thanks, but I really wanted to what your own definition is; we have discussed it a lot in our own shop, and I wanted to hear other takes on Done :-)
GertGregers
+1  A: 

There are three nice articles by Mitch Lacey, Dhaval Panchal and Mayank Gupta on this on the ScrumAlliance website.


EDIT: Basically the whole point is that done is defined on a project-by-project basis by the team. The basic need is to agree on the definition, not what the definition is.

Sklivvz
+5  A: 

I'd say it is up to your team to decide. Talk with the product owner. Ideally done would be when a story is in Production and being used. However, there is a time gap between when a story is development complete and in Live. Makes it hard to track how long a story took to develop.

In my team, our definition of done is, when the developer completes a story,and does a "show and tell" to the rest of the team(testers, product owner), and if everyone is happy it goes into the subversion trunk.

Further testing is done off a automated build from trunk.

Hibri
+2  A: 

In a perfect world, the product shall be in a shippable state at the end of every iteration.

Now this actually depends on your product, your market, your customers and might not be possible.

If you cannot achieve this, then the next planning horizon apply: the release. The Team as a whole should decide what is required to ship the product and plan accordingly.

What helps here is to define "done" at the task level. Defining done here is much more simple: one task is done when you can start another one: everything is tested, integrated. The Team can alo define this state: documented, reviewed, included in automatic build, no known problem, accpeted by On-Site Customer ...

Having all your tasks really "done", Having all tour backlog items (or User stories, whateveryou call them) realy "done" allow to be "done" at every iteration, which helps preserving the product in a shippable or deployable state.

philippe
+1  A: 

Great question! There was a similar question that was asked a while back that might be useful.

Scott Saad
+7  A: 

We at TargetProcess use the following definition of Done for user story:

  1. Short Spec created
  2. Implemented/Unit Tests created
  3. Acceptance Tests created
  4. 100% Acceptance tests passed
  5. Product Owner demo passed
  6. Known bugs fixed
Michael Dubakov
If a bug doesn't prevent an acceptance test from passing and for some reason doesn't get resolved in a given sprint (time-frame), I suggest it should NOT be on the list of requirements for saying something is done. These types of bugs should be put back on the back log and prioritized by the product owner. When you do a retrospective there should be a conversation about how good your doing acceptance testing.
Jay
A: 

Everything that will make your "stabilization period" (ie work required between the code freeze and the release to the client) shorter.

louisgab
A: 

Here's a nice Movie about the Definition of Done.

Doro