What Should Done Mean, Coda

Last week at Agile 2010, Joshua Kerievsky and I facilitated an Open Jam session (open space) about what done means. We discussed a variety of points. I believe we eventually agreed that context matters.

  1. It’s important to know what your product success criteria are. If you don’t use a project charter where you define success criteria, consider doing so. (Yes, in Manage It!, I have a discussion on what success means. I have downloadable templates too.)
  2. You also need to know what your release criteria are–when is the product good enough to release?
  3. Do you have a product that can be continuously deployed, or does it need to be deployed discretely?

Success criteria are not the same as release criteria. You may decide to release something now, to get some feedback from some customers, even if it doesn’t meet the product success criteria. Your success criteria might be about the process, not the product.

For products that can be continuously deployed, you can obtain customer feedback, so you can consider an approach that says done isn’t done until customers accept it. I didn’t ask then, but I will ask now: what happens if some of your customers really like the feature and some don’t? What do you do? (The benefits of sleep :-) Which customers do you listen to?

For products that don’t lend themselves to continuous deployment, you have some options:

  • Make sure you have iteration goals. For each feature on the backlog, before you start it, ask “How does this feature move us closer to our project release criteria and product success criteria?”
  • If you don’t have iteration goals (you may be using kanban)  ask, “How does this feature move us closer to our project release criteria and product success criteria?”
  • At the end of an iteration, or periodically if you’re using kanban, ask “How are we progressing towards our release and success criteria?”

If you have someone grooming the backlog, I would assume that person is asking those questions. However, we all know about assumptions. Maybe making the assumptions explicit is the right thing to do.

A holistic approach to a product is a good thing. If you can work with your customers, that’s great. And, many of us work on products where we either don’t have customers yet (we’re creating a market or we want to be quiet for a while to manage the competition risks), or where we cannot do continuous deployment. Thinking about done for the feature makes sense then.

I still want someone guiding the product, who is not a technical person. That person would ask the question about moving the product forward to our criteria. That person knows when there is more business value to create and when we have enough for now.

For me, done is still feature-based. Maybe some of you think I draw the circle too narrowly around the project. Maybe I do. But I still meet agile (!) teams who say, “We finish a feature and hand it to QA.” Sorry, to me that’s not done. Until I see more teams taking a holistic approach within the technical work to finish a feature, I want team members to know when they are done and when they are not.

2 Comments

  1. Great post on “DONE.” There is a big difference for many players in the development process.
    QA “Done” does not equal DEV “Done” and so forth.

    It may help to also include a point about how Design elements fit into it. What are the requirements that dev and QA need from Design to consider it ‘done’?

    Reply
  2. Well, it seems DONE remains ambiguous to players and managers. I guess what matters is what teams have done, so to speak, and everything else will follow.

    Reply

Submit a Comment

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>