Monday, December 24, 2018

Agile and the V-and-V thing

Have you thought much about this? Two of the conceptual conundrums of the hybrid methodology project are:
  1. How do you verify that which is incomplete and
  2. 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 practises that are difficult to map directly into the Agile domain. Traditionally, V-and-V has these practises:
  • 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
  • Verification: When development is complete, and when integration of all requirements are complete, the roll is called to ensure that every validated requirement is present and accounted for.
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 is generally a practice at the iteration level, verifying that iteration backlog matches the iteration outcomes, and logging any differences
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.

Buy them at any online book retailer!