Done or Complete? How to develop in iterations.

This topic is closely related to that of “Continuous Refactoring” which I am constantly nagging about. It is also related to “Definition of Done”, which is another favorite topic of mine :-).

When are you “Done”? The right answer is: When the Story meets the definition of done. Let’s say your Definition of Done says “Releasable”. So, the Story is done when it is Releasable. Great. But, wait… What does that mean, “Releasable”?

Coders are creative people. I touched this subject in my previous post “1-day remaining forever”. We want to do an excellent job, not just an average one. We want everything we ship to be just right, because bad solutions or sloppy code reflects directly on us and our abilities and creativity. So it’s easy to get stuck in the “almost done” mode, coz we want to polish that extra method or just fix that last design flaw or just rewrite that last class which was poorly written two years ago... So when faced with the goal line (i.e. the point when we’re “Done”) we really want to go to lengths to make sure everything we’ve done is really “ready” and fully thought through, and future-proof, and so on.

But the point I am trying to get to here is that there is a difference between “Done” and “Complete”. Every story needs to be Done in the sense that it fulfills our Definition of Done. But that does not mean “Complete”: it does not mean e.g. “future-proof” or “with architectural perfection”. Those states are achieved over several stories – over several iterations. This is why we call Agile development Iterative. So, think of it like this: “Done” is something we do with each story and each sprint, and “Complete” is something we reach over several stories and several sprints.

I’ve seen it several times; developers dig down into the system and try to solve problems that are of much less priority than the story at hand, e.g. by designing or preparing for some story that is much further down in the product backlog. This behavior builds dependency between stories, it breaks prioritization and it adds a lot of insecurity to the estimates. The proper approach is to focus on the immediate story only, and effectively staying within its boundaries. Trying to stay within the boundaries of a story requires discipline and (not least) a good understanding of Scrum and continuous refactoring.

To sum things up: Aim for “Done”, not “Complete”.

Until next time..!