Skip to content

"I know it doesn't work but it's done" - a story about the definition of done

November 28, 2008 by Przemysław Bielicki


Picture courtesy of orinrobertjohn@flickr

Some time ago I was talking to engineers responsible for some part of the software and I was asking when they will be ready for production. In other words I asked them when their features will be ready. They told me that they are ready now. What was my surprise when I tried to test their software and discovered that about 50% of cases were not working at all. So I asked them why they told me that they are "done" when they haven't even implemented half of the planned features? They answered me: "We know it doesn't work but it's done - we implemented something so it's done. Now we have to work on quality i.e. implement rest of the features."

When I heard this I think I might have looked like the lady from the picture. I couldn't believe someone can think like this - if we implement one use case out of one hundred we can consider the project done? The rest is the "quality"? I don't think so.

In this post I'll try to explain once again what is definition of done and why it's so important to have the same definition at least among all the people involved in the development of a single project.

Let's define "Done"

I would say that there is no one, good and universal definition of done. You can find some discussions in the Internet about it but you can see that everyone has it's own variation. So do I - in my view the most important things are (I will use "user story" word meaning every variation of request, use case, user story, etc.):

  • user story has to be implemented, today (no 99.9% is accepted)
  • user story has to be tested and no known bugs should exist
  • user story is ready to go into production, today
  • user story has to be ready to be presented to customer, today

Some explanation

User story has to be implemented - means that the code has to be committed to the version control system (like CVS, SVN, etc.), documentation should be available on Wiki or in the VCS, etc. It means that the output of the work done (whatever the work to be done was) must be available for anyone in the company to be downloaded in some way and checked. There must not be "I have it on my box - will publish it soon". Work must be committed and available for others.

User story has to be tested and no known bugs should exist - means that if you know about any bugs in the user story you're going to deliver - it's not done. If it exists in some subpart of the user story and you really need to deliver the working stuff, maybe you should split this user story into two, smaller ones. You must not deliver bugs to your customer - I'm talking about bugs you're aware of.

User story is ready to go into production - it means that it is ready to be deployed at any time from the time you stop talking. The wise thing would be if the working software is already deployed and tested in the production system - if it works - it's really done.

User story has to be ready to be presented to customer - it means that within 30 minutes (max) you are able to prepare presentation of working software to your customer. Of course, it requires you to have list of acceptance test ready and you know how to demo your software. The last point of it is very very important. Remember about it when defining all your user stories - you have to know HOW TO DEMO USER STORY - it will probably help you defining acceptance tests (e.g. user adds new item to the database using HTML form, then goes to the search panel and is able to find newly created item by its name, ....).

Wrap up

As I mentioned above good and universal definition of done probably does not exist but at least many resources agree on base principles. My definition of done is simple but I consider it quite powerful.

If you are interested in diving more into the subject I would recommend those two links from ScrumAlliance:

What do you think about my definition of done? If you have your own I would gladly read about it. Please share your opinions here.

About the Author: Przemysław graduated from Gdańsk University of Technology in 2004 having specialized in Distributed Information Systems. He worked in Lufthansa Systems, Intel Corporation in the past where he developed complex IT solutions in many Java-related technologies. In professional life he is a real Java expert holding couple of Sun Java certificates (Programmer, Developer, Web Developer) and Certified Scrum Master, of course.

Przemysław is a regular contributor to AgileSoftwareDevelopment.com and the author of "From Java to Java EE" blog. He now works as a Software Craftsman in an international company that is the leading Global Distribution System (GDS) and the biggest processor of travel bookings in the world. Contact Przemysław

Comments

Conclusion: If you're done,

November 28, 2008 by beza1e1 (not verified), 5 years 39 weeks ago
Comment id: 2064

Conclusion: If you're done, you don't have enough user stories OR no software is ever done.

I'm not sure you understand

November 28, 2008 by pbielicki, 5 years 39 weeks ago
Comment id: 2065

I'm not sure you understand the idea ;) The idea is not to have 100% of user stories done but to define when the story is done. Not the whole software - in one iteration you have to deliver 10 stories in another one it will be 8 stories. It is not the definition of "software done" but the story/feature done.

Hope it helps,
Cheers!

Not the programmer's thing

November 28, 2008 by Anonymous (not verified), 5 years 39 weeks ago
Comment id: 2066

In our experience, when a client / projectmanager / any obviously technical moron asks to create something it involves making something that actually doesn't work or he/she doesn't want. Meaning that most things made by programmers around the world either don't work or will never be used because the 'client' doesn't like them.

In a lot of these cases 'it's done but doesnt work' is a completely valid statement and not the programmer's responsibility. Easy to say for a client or some lame management type who knows nothing that 'it should work' while programmers built exactly what they asked. And ofcourse that was never supposed to work.

Not saying you are like that, ofcourse your 'user stories' are unambiguous and perfectly logical and leave no possibility for done-but-not-working. But in general...

PS I am a manager and a programmer and I often write bad specs/userstories after which I just have to accept the total garbage that comes back from the developers. Nothing to do about it.

The user story itself defines the done condition

November 28, 2008 by Dennis Sellinger (not verified), 5 years 39 weeks ago
Comment id: 2067

When implementing user stories, there is normally a section in the story called the "Acceptance Test". In my experience this is the thing that is used to test whether or not the story is completed. If the acceptance test is not met, don't close the story. If it is met and you aren't doing everything people want, create a new story.

The problem is that the acceptance test typically describes what must happen in a line or two, so sometime when you meet the acceptance test there are things that are clearly complete. In this case, have to open a new story or a bug (if a specific case is not correctly implemented).

Saying that we must never have known bugs is a bit of false good thing. We always have to use judgment in whether or not the "spirit" of the acceptance test has been met and whether or not a bug is a stopper.

User stories are not features. A user story means that we have implemented enough code to perform an action. A feature is another thing all together. The scope of such is not so well defined and there is rarely a 1 to 1 relationship between user stories and features.

This blog post should be renamed...

November 29, 2008 by Steve Streza (not verified), 5 years 39 weeks ago
Comment id: 2073

...to "How to prevent your software from ever shipping."

You're almost right

November 29, 2008 by pbielicki, 5 years 39 weeks ago
Comment id: 2074

... but it should be renamed to ""How to prevent your crap from ever shipping."

key point - small user stories

November 30, 2008 by Anonymous (not verified), 5 years 39 weeks ago
Comment id: 2075

Some of the comenters miss a point that is self-evident if you work in agile processes for a while: A User Story is not a large peice of work and you will never complete all user stories. If stories are large or you believe you will complete all stories ... then you won't ship. That was not the authoris argument.

We company limits stories to less than 1-3 weeks of work. That is, in 1-3 weeks, I don't have every feature the product requires, but I have a software that does at least 1 thing very well. We obviously have a number of major features and products that require much more than a few weeks of work, but we still drive at them one small story at a time.

Best of AgileSoftwareDevelopment.com