Such a vital question in the software development world! “Doneness” is how you measure progress. And so it seems important that we should create some definition of the term.
I was recently asked a series of questions and decided to create blog posts from the answers.
Everything herein came straight from this horse’s mouth. I didn’t once flex my Google-fu or Bing-kwondo except to determine the best way to spell Bing-kwondo. My goal was to respond to the proposed questions solely with the knowledge I’ve gained from experience over the years. When reading my response, please remember – with passion comes opinion. I value your opinion, even if it is different from mine, as difference breeds understanding and growth.
Definitive doneness can only be determined if all parties involved fully understand the scope of work requested, the level of doneness requested, and if the work was completed fully at the time of the request.
And that’s hard.
In my experience, a software product is rarely ever done, and “Is it done?” by itself is rarely ever a suitable question.
Individual work items are completable, but false positives arise when:
- Team members don’t fully understand the work item
- Team members don’t fully read the work item
- The work item doesn’t fully document the scope of work to be completed
- A required work item doesn’t exist
- A completed work item doesn’t line up with company objectives
- A team member lacks humility or courage
A great developer strives to understand what “done” means and sets necessary expectations, ideally without using that vague developer speak that always seems to frustrate higher-ups.
In the same vein, a great developer goes above and beyond to exceed expectations, certifiably completing tasks, even when confronted with adversity.
Or we just lie about something being done and stay up for the next 36 hours knocking it out before anyone notices. :)
What’s your definition of “done”?