Josh Kerievsky has an intriguing post about Redefining Done. The idea is that a story is not done until:
A story isn’t done until it is being used by real users in production and has been validated to be a useful part of a product.
I have trouble with this definition:
- The development team is dependent on other people getting the product out to the users, especially in the case of shrink-wrap, or a hard product. The development team cannot deploy the product alone. (Rarely can a development team deploy a product alone, but it’s possible with SaaS. It’s not probable! For other products, you need a program team or some other mechanism to make sure the marketing is done, the bill of materials is created, etc. Deployment is almost always separate from development. I’ll blog later about whether it should be.) Just as release criteria need to be under the team’s control, the definition of done needs to be something the team can accomplish.
- The development team is dependent on the users actually using the product. To me, this violates the separation of what to build (from the product owner or customer) and the how to build it (from the development team). There is one person, a product owner or customer talking to the team. Yes, that person needs to know what real users will use. And, I don’t see how a team could talk to a gaggle of users and know what to build. The organization’s strategy is part of what to build.
- It’s possible that you would have an entire release of product waiting for “done.” Features would be some sort of done, but not all the way done, because the users had not used the product and validated it. This violates–for me–the notion of being done for now, but having demonstrable, releaseable product at the end of an iteration or when a card is marked done.
I see that the feedback from real users is helpful, maybe even necessary. I’ve been on projects where I certainly would have liked the feedback earlier than at release. Maybe the real value of this definition is to jiggle us into thinking about how to get feedback from users earlier, in the same way as in How Short Can Your Iterations Be? Thinking and rethinking about what done means (or how long your iterations are) to reduce waste in the project and deliver a useful product is a good thing.
I still have trouble with done not being under control of the development team. If a user or user surrogate has explained what he/she wants, and the development team has implemented it, and that person has seen a demo or used it, I have to believe the feature is done.
I’m not convinced that expanding the definition of done helps a project team. It does help us think of the obstacles that prevent us from obtaining feedback as early as a feature is complete. I’m still going with the idea that done needs to be under the control of the development team.
