Musings on project management: V and V in the Agile domain

Thursday, March 12, 2015

V and V in the Agile domain

Here's some draft text from chapter 5 of my up-coming 2nd edition to "Project Management the Agile Way"

Traditional V&V: the way it is

Traditional projects rely on validation and verification (V&V) for end-to-end auditing of requirements:

Validation: After structured analysis, and before any significant investment in design, the requirements ‘deck’ is validated for completeness and accuracy. If there are priorities expressed within the deck, these priorities are validated since priorities are influenced by the dynamics of circumstance and context
Verification: After integration testing, the deck is verified to ensure that every validated requirement was developed and integrated into the deliverable baseline; or that changed/deleted requirements were handled as intended.

Agile V&V: the way to do it

Agile projects are less amenable to the conventional V&V processes because of the dynamic and less stationary nature of requirements. Nonetheless, the spirit of V&V is a useful and effective concept, given the danger of misplacing or misstating:

Validation: After the business case is set, some structured analysis can occur on the top level requirements. Typically, such analysis is an Iteration-0 activity. As in the traditional project, and before any significant investment in design, the requirements ‘deck’ is validated for completeness and accuracy insofar as the business case defines top level requirements.
If there are priorities expressed within these business case requirements, these priorities are also validated since priorities are influenced by the dynamics of circumstance and context
Conversational requirements are also validated, typically after the project backlog or iteration backlog is updated. However, individual conversations often don’t have sufficient context for effective validation. Thus, some judgment must be applied. Multiple conversations are aggregated into a larger scope scape and validated for completeness, accuracy, and priority.
Verification: After integration testing, the deliverable functionality is verified to ensure that every validated conversation was developed and integrated into the deliverable baseline; or that changed/deleted conversations were handled as intended.
During development, we can expect some consolidation of stories, and we can expect some use (or reuse) of common functionality. Thus, we are not suggesting that Agile is to maintain a fully traceable identify from the time a conversation is moved into the design and development queue to the time integration testing is completed. However, the spirit of the conversation should be there is some form. It’s to those conversational forms that verification is directed.
In some organizations, verification is seen as just a part of integration testing; the last thing you do before signing off on a completed test.