Defining Done

Defining Done

Paul Parker

Blogpost Image

The business transformation journey often requires a systems transformation to enable the business to be more agile in the market, improve customer loyalty and satisfaction, while optimizing cost structure. For system transformation or upgrades using agile, the question of how do you know when you are done frequently arises. How do you know if you are spending too much time getting to the perfect solution vs. good enough to advance and move to production while meeting the business need? Once in production, further elaboration and enhancements can be made. In many cases, the target changes due to market or regulator factors, resulting in the implementation of a solution that varies from its original concept of perfect. So, why spend all that time on creating a perfect solution when over time, that solution will change?

Considerations in Defining Done

Routinely with agile projects, defining “done” takes into account what is required by the business and technical teams to communicate the desired business functionality to build and test the application. Defining “done” also needs to take into account the full lifecycle of the product during the solution definition phase, through delivery and post-production.

Questions to ask:

  • Does the current application meet current and near-term future needs and business drivers?

  • What are the new features in the new application or upgrade?

  • How will the new features advance the business transformation without customization?

  • Have the business drivers for the new system or upgrade been used to prioritize new or required vs. longer term wish lists?

  • Is there direct traceability from business drivers to requirements to system capability?

  • Are technical, functional and data requirements met? Are they documented?

  • Are process flows aligned to functionality?

  • Is the documentation complete enough to the production team?

  • Has post-production support been defined and put in place? Does it include:

  • Identification of the support team

  • Transition plan from development team

  • Resolution of third party considerations

Steps to Take:

  • Review business process

  • Review functional requirements

  • Assess business rules

  • Analyze design documents

  • Study and assess new application or upgrade features and release notes

Potential challenges along the way:

  • Business processes are not documented well or are out of date

  • Business rules are embedded in the code and not easy to extract and review

  • Formal design documents are inadequate, out of date, or non-existent

  • Current application is not well documented

  • Embedded notes on the application lacking the context of the business process or business capability it supports

  • Poor understanding of how current code fits into the overall business process

  • Lack of an understanding of why a business rule was implemented (e.g. regulatory compliance, client need, internal requirement)

In summary, defining done is more of an art than a science and requires close collaboration with the business owners, stakeholders and the development team. The goal should be getting the right solution into production with the right level of effort in order to realize benefits as early as possible. We will examine the different facets of “Done” in future blogs.