Are we there yet? Defining “Done”

When is a story done?

When the developer is finished? When it passes QA? When the business signs off? When it’s scheduled for a release? When it’s checked in to a release build?

Or is it when the feature is actually in production delivering value?

It’s likely that it’s some combination of the above, and that the answer will vary from team to team, and possibly from story to story. Having a general consensus on the team about what “done” means is important, because without it, we’re going to have confusion.

Accordingly, during the formation process, teams should spend time discussing what their shared understanding of “done” is and recording that in a wiki (or on a poster, or something – just make sure it’s recorded and available to refer back to).

I suggest timeboxing this discussion to 30 minutes. That should be enough to get to at least a high-level understanding. If you’re not close after 30 minutes, get help from a coach to create a compromise position and discuss it in your next Retrospective.

Example

A feature is Done when:

  • It passes all Acceptance Criteria
  • It passes regression testing
  • The requester has seen and approved it in non-Prod environments
  • All unit and functional tests associated with it are passing
  • It’s checked in to Main (if it’s a code change)
  • It’s scheduled for release to production (if it’s a 3rd party change)
  • Monitoring is in place (if applicable)
  • Support documentation is in the wiki (if applicable)

Leave a Reply

Your email address will not be published. Required fields are marked *