Monthly Archives: August 2011

It’s Only….”Mostly Done”

A good measure of how mature your Agile process is to ask “what is your team’s understanding of done”.  Does being done mean all the tasks are complete, does it mean that the developers have implemented the feature to their satisfaction, has it been tested by QA, does it mean that it has been demoed for the product owner and she has accepted it.

Recently our team had a story that was “done” and we took credit for the points in our iteration.  But a few days after the iteration ended there were a few more check-ins against the story.  Nobody was trying to hide anything, it was brought up at the daily stand-up, but were we really done at the end of the iteration?  No.  It reminded me of a great line from the movie The Princess Bride where Miracle Max says

He’s only mostly dead.  There’s a big difference between mostly dead and all dead. Mostly dead is slightly alive. With all dead, well, with all dead there’s usually only one thing you can do…Go through his clothes and look for loose change.

Miracle Max - Early Agile Evangelist?

The Agile corollary to that is

There’s a big difference between mostly done and done-done, with done-done there’s only one thing you can do…Go through the backlog and look for new stories.

Being done-done requires that the team understands the story, that there is agreement to how it will be tested and verified.  The story should be demo-able and the product owner needs to be available to clarify questions that inevitable come up during implementation.  It also means that other parts of your software process are followed, e.g. code reviews, documentation, etc.

If your team doesn’t have a common understanding of what done means, you are in for some trouble.  There is a lot of pressure to be done, and nobody wants to take zero points for a story that had a lot of work put into it.  But a false sense of being done is worse.  You may end up building up a lot of technical debt and won’t have a sense of what your true velocity is.

Be honest and open about what your understanding of done is.  Talk about it with others on the team, address it at your retrospectives.  Everyone on the team needs to be in agreement, both in general terms and for individual stories.

Advertisements