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,

1. Each team agrees upon a set of criteria implicitly required of all tasks in order to be considered not just Done, but DONE. 
2. Each team agrees upon how to write Task Descriptions in order to capture the intent of the task unambiguously

Sample implicit criteria shared by all work

The lists below outline some implicit “Done” criteria shared by successful product development teams that I’ve observed throughout my career. A developer should be able to answer “yes” to each item. 

Feature complete

• I have run the code at least once locally in my dev environment end to end

• I have run the unit tests and they pass

• I have added any additional unit tests where applicable

• I have run front-end unit tests where applicable. In the absence of unit tests, I have done my best to navigate through the UI to uncover possible regressions

• I have worked through a full understanding of the feature with the Product Owner and identified the various use and edge cases

• I have engaged the stakeholder, demoed, and gotten approval

• Onboarding new clients onto this feature is automated & documented

Systems complete

• I have performed any infrastructure changes necessary in production

• I have automated all those tasks as much as is reasonable – at the least, I talked to the Infrastructure (or SRE) team about it and possibly submitted an Infrastructure request if applicable. 

Sustainability

• I have added a new item in the OWNERS file or relevant other location 

• I have documented the feature

• I have added relevant metrics

• I have added appropriate alerting & associated runbooks (e.g. internal documentation site)

• I have sent out a PSA and/or Chat and/or engaged the team appropriately

Writing Unambiguous Tasks

In my experience, the quickest way to get unambiguous task descriptions is adopting the User Story format.