Skip to main content



Done When?

Dangers of not being done Successful software teams share many similar team norms. One such norm is the ability to quickly answer the following question by reflex – What does it mean to be DONE with my task? At first glance, it seems easy to answer this. Doesn’t it just mean that I wrote the code to do the thing the product owner asked? Good question. Unfortunately, that’s only half the battle. That code has to run in a production environment and it needs to do the right thing. Ensuring both of those things will go as expected actually involves a whole list of other activities by the developer. Failing to complete those activities results in a bad day for many folks involved with the product.  So, what’s a developer to do? Two things can easily help, Each team agrees upon a set of criteria implicitly required of all tasks in order to be considered not just Done, but DONE.  Each team agrees upon how to write Task Descriptions in order to capture the intent of the task unambiguously Samp

Latest Posts

Logging in the Code and out

Don't Do Nothing

Looking for a Code Review? 4 Tips to Set Yourself Up For Success

Writing effective documentation

Give your tests a story

How do I prepare for my tech job interview?

How to safely kill your NTP server

git log exit code 141?

Yes, git, I did mean that

Starting an Open Source Office within your Company