So in this case a definition of "done" as "Functionally complete, with all images and layout" would have prevented the whole discussion.

These kinds of things are communication issues. If the project tasks are completed but the feature isn't really "done" then there may be some room for improvement in the task description and requirements gathering and documentation. For something like this, depending on the size of the project, of course, it may help to have a developer that is the final say on tasks. They know everything about the software, so they know what every feature should do. Call it "Scrum Master" or "Point of Contact" or "bellybutton", but they are responsible for closing the task when finished.

I worked for one boss long ago who was obsessed with the word "done." No one could ever figure out what his definition was, but he wielded like Thor's hammer. If software that had been deployed for six months broke and had to be fixed, he'd scream "I though you said it was done! Why are you still working on it."

This process of gathering requirements and creating software out of nothing, while managing so many different people, personality types, and areas of expertise, takes time to evolve. Make sure you have AARs (after action reviews) to evaluate your process. If something wasn't actually done, but everyone thought it was, figure out why. Was there something you could have done to see the problem? Is there something that could be done differently next time?

First, never let a developer who has wrote a feature to write a test case for it. The test case must be written for someone else before the developer starts to work. If the developer tells someone what to test, then the tester is useless. The developer is biased and will never think of testing some stuffs (say, put a 10000 letters text inside a "Username" input field). It's not because he's a bad programmer or he's stupid, but the developer is trying to make something work and all his effort is into that.

This is not possible if you have a really small team. I worked for years where there were many projects and only 5 programmers. Each person was completely responsible for multiple projects. Most of the developers didn't have tests for anything. The just hacked the code and prayed it would work.

Also, test driven development is based on doing exactly the opposite of what you're describing.

First, never let a developer who has wrote a feature to write a test case for it. The test case must be written for someone else before the developer starts to work. If the developer tells someone what to test, then the tester is useless. The developer is biased and will never think of testing some stuffs (say, put a 10000 letters text inside a "Username" input field). It's not because he's a bad programmer or he's stupid, but the developer is trying to make something work and all his effort is into that.

This is not possible if you have a really small team. I worked for years where there were many projects and only 5 programmers. Each person was completely responsible for multiple projects. Most of the developers didn't have tests for anything. The just hacked the code and prayed it would work.

Also, test driven development is based on doing exactly the opposite of what you're describing.

You're right, I forgot about TDD, but even in TDD you can forget some conditions, you code what's needed for you're tests to work, but you might miss some tests. And even then, you can't test everything with TDD, you can't do integration tests to see the whole flow of a user registering, receiving an e-mail, confirming with a link and loging in for the first time. The developer can do it, but there sould be someone else testing. I know it may not be possible in small teams, but OP was asking if a developer writes a test-case for QA impling that there's people available, maybe I shouldn't have write "never", but I thought it was clear what I was traying to say.

Depending on the task type, there's a different "definition of done".

I've also found myself redefining that definition in some different project contexts (often tech-dependant).

A feature is generally done only when all necessary art is integrated (if that's relevant) and it has been QAed. Basically, it's done when the client/PO can see it, or when the user could use it.

But we also have intermediary steps of done, which we have a custom (visible) workflow for. It basically tells us who owns a specific task and what's left.

The plus to that approach is that the PM won't bug the programmer asking if it's done, when clearly, all programming has been implemented successfully.