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