Have you thought much about this? Two of the conceptual conundrums of the hybrid agile-conventional methodology are:
- How do you verify that which is incomplete and
- How do you validate the efficacy of that which is yet to be conceived?
Verification and validation (V-and-V) are traditionally held to be very important project practices that to some may be difficult to map directly into the Agile domain, to wit:
- Validation: Each requirement is validated for it’s business usefulness, in effect its efficacy toward project objectives.
Validation is usually not later than the last step in gathering and organizing requirements.
(Of course, in Agile methods, it's allowed to change the requirements book on the fly according to customer feedback about interim results, so there may not be a well defined "last step".) - Verification: When development (construction) is complete, and when integration of all constructed requirements is complete, the roll is called to ensure that every validated requirement is present and accounted for. (See above re the changing book on requirements)
Validation
Placed into an Agile context, validation is applied both to the project backlog and to the iteration backlog, since changes are anticipated to occur.
Validation is typically first applied at the story or use case level, validating with conversation among the interested and sponsoring parties that the functionality proposed is valid for the purpose.
Placed into an Agile context, validation is applied both to the project backlog and to the iteration backlog, since changes are anticipated to occur.
Validation is typically first applied at the story or use case level, validating with conversation among the interested and sponsoring parties that the functionality proposed is valid for the purpose.
One can imagine validating against external rules and regulations, perhaps internal standards, and of course validating against the business case.
Verification
Verification is generally a practice at any level of construction and itegration, verifying that which was approved and prioritized in the backlog(s) is, in fact, found in outcomes. And, if not, any differences are logged as technical or functional debt.
Verification
Verification is generally a practice at any level of construction and itegration, verifying that which was approved and prioritized in the backlog(s) is, in fact, found in outcomes. And, if not, any differences are logged as technical or functional debt.
Depending on the project paradigm, V-and-V can be carried into integration tests and customer acceptance tests, again testing against various benchmarks and standards for validity, and verifying that everything delivered at the iteration level got integrated at the deliverable product level.
Is this an issue?
Is importing a really old idea of V&V into the Agile domain an issue? It could be.
V&V is systematic accountability, and many resist being held accountable to a planned narrative.
Accountability requires estimating as a prerequisite, and we know where that debate is going (Disclosure: I'm an estimator!)
The remedy: change the name; press on. Agilists have any number of alternate names for V&V, but at the end of the day, being accountable for efficacy and completeness is part and parcel to competent participation in the project domain.
Buy them at any online book retailer!
