Done is Done

For anyone that's worked in an Agile environment, you'll know how difficult it can be to write the definition of done for some stories. As I've talked about it in other posts, stakeholders and engineers have to work hard to make sure they first understand what requirements are before they can agree on what "done" really means. Whether you're defining what "done" means for a story, an epic or a whole project, having it in place and agreed upon with stakeholders is essential and invaluable.

This post is more focused on the day-to-day of "done", though. As a technical manager, one of my pet peeves is when an engineer says, "Yes, it's done. I just need to...". NOPE. Then it's not done. 

Maybe there are a couple bugs open that need fixing; maybe the deployment details are still to do; maybe there are a couple unit tests still to be written. The list could go on and on. As the manager, it's your job to make sure that "done is done" not only for scheduling reasons, but also for quality reasons. Being really meticulous about this also reinforces trust with your stakeholders. If you prove over and over again that done really is done, they'll know they can trust you.

So make sure that your team knows what you expect when a task is declared as done. They'll appreciate it and you'll be able to sleep better at night knowing that one less potential problem is addressed before it happens.