In his Herding Cats blog, Glen Alleman, asks a very pertinent question. What is the definition of done? Well?
Done (Enterprise software delivery project) – when software capabilities have been delivered that support the business value proposition per the customer’s business capability requirements.
In our agility, we recognize that requirements are clarified by “emerging information”. That doesn’t mean that they “change”. When a requirement “changes”, it is effectively a new requirement. We often experience a case where the business value proposition is inadequately defined at the outset of the project. In this case, it is necessary for this requirement to be clarified by emerging information.
We also recognize that there may be different paths to deliver different software capabilities that support a particular business value proposition. Chosing a different path or delivering different software capabilities that support the same value proposition does not mean the requirements have changed, more likely that we are responding to emerging information.
I like to break requirements into business capability requirements and software capability requirements. Regardless of your project methodology you must contend with these facts:
Fact: Enterprise software projects are created to deliver some business value. The requirements should define both the value (business capabilities) and a path to deliver it (software capabilities). Requirements form the basis of the definition of done.
Assertion: If the business value does not change, there is not a new requirement.
Assertion: If during the delivery of the business value, we learn things about the domain, the technology, or the world external to the domain that alter the path to deliver the value – there is not a new requirement – but emergent information.
Assertion: How we manage the (the documentation of our understanding of) requirements is a method.
Fact: Some software projects are required to change course mid-stream. Sometimes the business value we initially intended to deliver is overturned by market pressure, financial impact, or a change in management or strategy.
Assertion: When the business value for a project changes, there is a new requirement.
Assertion: When the work done toward that value is abandoned, there is a loss.
Assertion: How we manage the (documentation and accounting for) change to requirements is a method.
—
Recognizing that there is a difference between allowing emerging information to clarify, influence, or stabilize the delivery of value and accounting for changes in the definition of the value stream for a project is key to understanding agile and how agile methods manage both cases.
—
In either case, the definition of done is when we have delivered working software capabilities that support the business value proposition(s) that have been “commissioned” by the customer.
No Comments