“Done” is the Wrong Measure of Success

It’s a very important thing for any agile team to find a definition of Done, which fits the expectations and the environment of the current development. For User Stories, I definitely prefer Done = Released as the most helpful metric. Only if a story is really out there serving users can you truly forget about it. Or can you?

The Lifecycle of a Feature

In my introduction to a Kanban Board for Features, I emphasized that a Feature is the unit of work for strategic product management and can be cut into User Stories for a smooth development flow. If one, or even all, of the User Stories which comprise a feature are Done is the feature Done, too?

Unfortunately not. On the contrary: As soon as the feature is finally out there the most important phase starts. Now, it’s time to measure the (hopefully) positive effect of the feature and compare it with the expectations. Does it live up to them? Or not yet?

A Feature is Done, if it is Successful

More often than not you’ll find out, that your feature is nice, but not as good as expected. Now it’s time to take a critical look and do some root cause analysis. Why does it fall short of expectations? Ask five times “why?” to identify things to change. Then, move the feature from Released to In Progress. It has not reached it’s final state: Successful.

Only thinking in User Stories is too short sighted, even if you have the already quite good definition of Done = Released (which too many teams are far from using). To ensure long term success of the software you build, you need to make sure that the features you build are successful. This usually needs a couple of iterations after releasing a feature. Only if you accept that and measure your progress, will your software become truly successful.