And continually revisit it. When you're knee deep in requirements, corner cases, and industry best practices, you can lose sight of why you were building the damn thing in the first place, and end up with something that doesn't satisfy that need.
How do you define done? Software is never done.
A better way to look at things is whether a feature is in good enough shape and whether moving on to working on other things is likely to be more beneficial.
You're not building "software," you're building something for someone to use. Done is defined by what that person needs to do their work. Done should be defined up front, or at least as far ahead as possible so it's clear.
One of the first questions I ask when probing about the state of a project or task is "how do you know when you're done?" Too often, the answer is a shrug, or a deer in headlights look!
