OmbuLabs Blog

The Lean Software Boutique

Our Definition of "Done"

Quality should be present in everything you do, but it should be balanced with the time you spend working on a feature. Does it feel like you've been working on this feature for a really long time? Maybe you have. Is it "done"?

That is a tough question, so I'll write down our definition of done.

When is a feature done?

  • The feature does what it is expected to do
  • If it has a user interface, the UX is simple and good enough: A human can use it!
  • If it is code for other programmers, the public contract is clear: A programmer read the documentation and use it
  • It has a decent spec, which covers at least two scenarios (not just the happy path)
  • It is fast!
  • The build passes (it doesn't break any of the existing specs)
  • The code is easy to maintain (DRY'ed)

Have you spent 2 days in a feature that should've been done in 2 hours? Have you spent 2 hours on a bug fix that should've taken you 8 hours? If so, why?

If the feature is big, break it into smaller features. This will make it easier to move ahead.

Before you submit your pull request, make sure that you have considered this list.