Sometimes the simplest of words spark the biggest debates. In programming, defining the word "done" has a diverse field of opinions. Some of the primary drivers for defining "done" are for clarity and efficiency. In many situations, teams devise a guiding statement or build a check list of necessary steps. For example, a guiding statement might state, "A feature is complete when it meets the requirements laid out by the business and has been released to customers." Although the simplest of statements can still generate disagreement, teams can typically find common ground on defining "done." Once alignment is found it's tempting to declare "mission accomplished," but teams should dig a bit deeper.

While programming, developers cross many decision points that bring into question a different, lower-level definition of "done." For instance, how far should something be architected? Scaled? Fault tolerant? Another example is fixing a bug. How far does one go to fix the problem? Should the surface level issue or the underlying problem be fixed? What happens if fixing this issue exposes/creates other bugs? Although some of these questions can be answered through fact finding missions, others are less concrete. When these situations arise, keep the following thoughts in mind:

• Can direction or advice be provided by a lead, manager, business analyst, stakeholder, etc.?
• Is the complexity of the development approach less than or equal to the value of the functionality? For example, a seldom used admin page may not require the same level of attention as other high traffic areas.
• Which area of programming does the functionality fall into? Good enough, solid, or reliable?
• What is the priority of the concern/problem? Does this need a short term or long term solution? Or both?
• Do other priorities supersede the importance of this?
• What are the risks of going with that decision? Are other risks exposed by not selecting that decision? Will/does this negatively impact the software? By how much? Is that within an acceptable range?

When using these guidelines, it's beneficial to have multiple solutions in mind when possible. This helps safeguard developers against snap decisions, inattentional blindness, and groupthink. If one solution introduces too much risk or investment of time/money, having other predefined options is invaluable. In working through this process, it's important to remember that there is no silver bullet. Each environment and company is unique. Use this list as a jumping off point and feel free to enhance it. This will help developers in the daily decisions of crawl, walk, or run. Having alignment on these lower-level "dones" will help ensure the larger "done" is achievable.