The “Done” Dilemma in Project Management
If you manage an engineering team, removing the Done status from your PM tool is the last thing you would do. That idea won’t even cross your mind; you want your developers to get stuff done. But what if I told you that your beloved Done status is a double-edged sword, hindering progress instead of helping it?
Roadblocks Disguised as Best Practices
I’ve seen how tech leads and peers get in the way of getting things done as if they did not want a specific task to reach the Done status. Here are a couple of examples:
1. Overzealous Code Reviews
We’re talking about asking for changing variable names. If your company has a standard for variable names, or the developer used a crazy 500 characters variable, that makes sense, but that’s not the case in most cases.
2. The Dreaded Scope Creep
Suppose you don’t have a user story written or an acceptance test. A ticket lands on QA, and the person testing the feature asks for changes. In that case, it is very easy to introduce last-minute changes that will put a ticket back in progress, throwing a wrench into your project management plans.
3. The Done Done Syndrome
Some startups might consider Done Done when something is in production. A feature might never be in production for many reasons, but it doesn’t mean it is not ready – I mean, “Done.”
Escaping the “Done” Trap
So even if you don’t delete the Done status, you may unwittingly contribute to these roadblocks.
What’s the solution, then? Have code guidelines, write user stories and acceptance tests, and loosen up the SDLC a bit.
