Setting a Clear Expectation of Done

February 05, 2013

By

This post is a continuation of the series, The Art of Accurate Software Estimation. Thus far in the series, we have been setting the organizational and business context in which an estimate is presented. In this post, we’ll see how formalizing a Definition of Done will help improve estimates, increase transparency regarding the cost of software and establish the expectations of what successful completion of a feature really means.

Start with the End in Mind
My wife is an elementary school teacher and her school incorporates Stephen Covey’s seven habits of highly effective people into their entire curriculum.  Regardless of how this brainwashing strikes you, habit number two, start with the end in mind, represents exactly what I mean by setting a clear expectation of done. This is what we call The Definition of DONE. At MHM we talk about things being lowercase “d” done and uppercase “D” Done. Lowercase done means that something is functional, but the developer isn’t ready to stamp it ready for QA. Uppercase DONE has been given a formal, documented definition that has been agreed upon as a group. It is a commitment we have made to ourselves as much as it is to each other and our clients.

While you could think of it as a compliance checklist, I prefer to think of it as a level of craftsmanship that evolves with the development team and business owners throughout a project. This isn’t a stone tablet of “thou shalts” or “upon punishment of death” style statements, but it is a formal commitment that the team is making to one another and it should be taken seriously. It is something to review during retrospectives and should be easy to amend if crucial items are missing or when something proves to be unrealistic.

A common reason that teams habitually underestimate is because it is extremely challenging to consider all that is involved with making software, production ready. With a clear Definition of Done in place, expectations of what production ready means is brought to the forefront of everyone’s mind, making realistic, and useful estimation possible. It sets an expectation of quality that would need to be specifically excepted should any quick and dirty solutions be kicked around, and it provides a starting point for navigating disagreements about the length of time estimated.

With all of this in mind, I’d like to share Mapleton Hill Media’s Definition of Done. First let me mention two more important comments on perspective with regard to the DoD. 1. Many things in your DoD might seem obvious, but it is the formalization and consensus agreement that makes obvious things important communication points. 2. It is challenging to get agreement from a large group of people, but don’t let that deter you. Even the simplest grounds for consensus are valuable contributions, offering a positive starting point for continued growth. With that in mind, I give you MHM’s Definition of Done:

Definition of Done for User Stories

  1. Code compiles with no errors and no warnings
  2. New code doesn’t break existing code
  3. Reasonable Documentation made available to the team (code comments where appropriate, word doc or wiki if available)
  4. Edge-cases have been considered (comment where edge-cases are ignored)
  5. Code checked into repository and available for others to pull
  6. Happy Path tested in all supported browsers
  7. Deployment and Environment requirements documented
  8. Code is unit tested and all tests pass (where unit testing is established)
  9. Confidence that user acceptance is likely
  10. Tickets in Project Management System are Up to date

Definition of Done for Sprints

  1. Demo to product owner
  2. High priority bugs are fixed
  3. Retrospective Meeting
  4. Changes from this sprint have seen several peer reviews

That wasn’t so hard, was it?

Thus far in this series on estimation, we’ve been discussing a lot of the context in which an estimate is being provided. We have covered some of the basics of the business environment, some general project management considerations and the importance of a solid definition of done. In next week’s post, we continue to distill the process by continuing this theme of implementation with a focus on my favorite topic, the importance of software frameworks.

Software Engineer
Erik Nelsestuen

Passionate for timely delivery of elegant, object oriented, test-driven web apps, balanced with a diet of mountain sports and plenty of fruits and vegetables.

Leave a Comment