I've been working in Product for over 15 years (please do not do the math to guess my age). So, I've been working with engineers for a long time. Despite that, I always have to remind myself that the definition of doneness is not universal. More than once, I've had conversations with my engineering teams about things being done that go like this:
I tweeted about this recently, and there were a bunch of interesting replies and questions. Here are my three tips:
- If you use agile, creating doneness or acceptance criteria for every story is overkill. It is too much work and time for not enough value.
- Doneness goes both ways, engineering and product design. I don't mean waterfall, or 10 page requirements documents. I just mean that there should be enough wireframe/design, user value, and business proposition fleshed out for engineers to reasonably spec out a prototype.
- Doneness isn't a laundry list, but a thoughtful framework by which we can determine the actual tasks that need to be done and create shared expectations.
My own doneness list for our internal products looks something like this (simplified for general understanding):
- a product outline that defines the value of this product (i.e. where it needs to exist), where it fits into our broader set of products, the core features that it should have, database reqs/schema
- designs for new UI elements and some inspirations from other sources
- update the database schema
- build the api integration for the internal products
- build the front-end changes to the internal products
- build the api integration for the user-facing portals
- build the front-end changes for the user-facing portals (web, mobile, etc.)
- create the integration tests
- user tested at least once by eng
- release into dev, with a clear outline of what features were introduced in this release and which ones from the product outline have not been released
Then, post this list in a clearly defined place - Google Doc, slack channel, etc. so everyone can read and access it, especially new people on the team.
And in case it wasn't clear, product should be collaborating with engineering and design to create the doneness list. Doing this simple task together can help set the right expectations (and estimates!) and avoid surprises and frustrations when it comes to doneness.