What does "done" mean? Well, it means you've decided that you're finished. With a task, a project, a JIRA ticket, whatever. But it's very possible that when you say you're done, you're actually 80% of the way to finished, and the last 20% will eventually come around to haunt you and steal your time and money.
Different Types of Done
There are many different valid types of "done". Here are a few of them I could think of, sorted by timeline (ish):
- Code works (matches a spec or design)
- Code produces accessible and performant UI
- Code is tested (either manually or automated)
- Ready for internal review (maybe a PR review)
- Ready for stakeholder review (client, product manger)
- Client has approved
- Client has given the go-ahead for launch
- Project is launched
- Internal team has recapped project internally, and "resolved" that project.
These are all very real states, but if you call all of them "done" you'll never know when you're really done, and you'll underestimate the amount of work left to do, and it will cause problems.
Problem #1: Frustration
When you say you're done with something, your brain believes you. So when you inevitably have to come back and finish the last 20% you get frustrated. Because you were done. It was finished. So, the work that should've included in the definition of "done", becomes nagging "extra" work.
Problem #2: Team Friction & Expectations
When you haven't defined "done" for your team, it's going to cause problems. Take for example a web agency with two developers and a project manager. Here's how they all individually define done:
- Dev #1: The project is finished when: it looks like the designs and it doesn't have any glaring functionality bugs.
- Dev #2: Everything that Dev #1 said, and: every page has lighthouse score of 90+, it has been audited for SEO issues, and every page is accessible and is at least AA compliant.
- PM: The project is finished, functional, matches the team's development standards, and: it has been documented, pushed to Staging for review, and you've set up users for any stakeholders who should have access.
You can immediately see where problems will arise. Dev #1 and Dev #2 are working with entirely different standards of work, and their PM is coming from a completely different perspective. This will cause friction, and lose you money.
Problem #3: Inconsistency
Do you think McDonald's got to where it was, a literal global superpower, without consistency? No, that's one of the things that made it great! You can step into any McDonald's in the World and ask for a #1 and you'll receive the same thing every time. Consistency is key.
Consistency is key, no matter what you're doing. You work for an agency? You need to produce consistently Good Work 😉 or your clients will work with someone else. You work for a product company? You need to produce consistent, stable software or people won't use it (or won't stay). Are you building a component library? You need to have a consistent API across components, and you need to make sure good documentation and examples are always written before you launch a new component.
In any line of work, defining "done" is a crucial part of producing consistent work.
How to define done
Talk with your (complete) team: Bring everyone in that you work with together, and come up with language and processes around what "done" means for each department, and each type of project.
Define done for each aspect of a project: QA should have a "done". Dev should have a "done".
Set up your workflow tools to recognize different "done" states: For instance, at Good Work, we have Trello columns for To Do, Ready for Review (internal), Ready for Review (client), and Done (which means really done).
Lastly
You might be thinking:
I don't have the power to define "done"
This might be true. You might not be a manager or even the most experienced dev on your team. That's fine! Start by defining "done" for yourself and communicating it clearly to your manager(s) and collaborators. Set clear expectations for yourself, and let anyone you work directly with know what your expectations of them are.
Disclaimer #1: I'm no expert. I've never taken an Agile course. I'm not a scrum master. I don't manage a team. But I work with a team, and I've seen when things have gone poorly and when they go well.
Disclaimer #2: I'm not the first, or last, person to write about this. This is one of the core principles of Agile (probably, who even knows) and so it has been covered in depth before me, and will be again after me.
Top comments (0)