We run projects with a bias toward clarity and momentum. Every goal has an owner, a date, and a defined outcome. Progress is communicated asynchronously, close to the work. And “done” means something specific — not just merged or deployed, but discoverable and useful to the people it was built for.
Definition of done
A project is done when users can see it, read about it, interact with it, and be delighted by it.
This applies to any shipped feature, product, or significant change. It’s not a gate that slows work down — it’s a shared picture of what “finished” means so the team isn’t surprised at the end.
Problem and solution are clear
- A clear problem statement exists and is understood by the team
- The solution has a defined scope: a specific list of things that, when complete, solve the problem
- Edge cases and explicit non-goals are documented
Shipped to production
- The work is deployed and accessible to all intended users
- No feature flags, manual steps, or prerequisites remain for end users
Consumer-ready
- Tested by someone in the role of the end user — not just the author
- Ergonomics, flow, and copy have been reviewed for clarity and taste
- Functional requirements are met and verified
Business review
- Reviewed for quality, brand, and tone
- Legal, compliance, or IP implications considered
- Pricing and packaging implications considered if applicable
Discoverable
- Documented — users can find and understand it without asking anyone
- Added to the Changelog
- Socialized internally (team demo, kickoff mention, or equivalent)
- Ready to present at a community huddle or meetup
Not every item applies to every project — a small internal tool doesn’t need a patent review. What matters is that the team has explicitly considered each area and made a conscious call, not skipped it by accident.
When in doubt, ask: could a user discover, use, and understand this on their own today? If not, it’s not done.