Defining Done: When to Crawl, Walk, or Run
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
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?