Pages

Monday, October 29, 2018

Validation and Verification -- in Agile? Really?

Validation and Verification: traditionalists know these ideas well. Do they still have relevance in the Agile space?

My opinion: Yes!

Traditional V-and-V: the way it is

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

Validation: the requirements ‘deck’ is validated for completeness and accuracy.

If there are priorities expressed within the deck, these priorities are also validated since priorities affect resource utilization, sequencing, and schedule.

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: what's to verify; what's to validate?

The BIG QUESTION: Is the strategic intent of the narrative answered? Is the business case on a path to success?

After all, the grand bargain in Agile is that flexibility for tactical implementation is allowed insofar as there is faithfulness to the strategic intent. Tactics are fluid; strategy is not.

Agile V-and-V: the way to do it

Certainly, Agile projects are less amenable to the conventional V-and-V processes because of the dynamic and less stationary nature of requirements.

Validation: After the business case is set, the top-level narrative is in place, and the overall strategy of the project is framed, some structured analysis can occur on the top level requirements.

If there are priorities expressed within these business case requirements, these priorities are also validated

Conversational-style requirements -- aka, stories -- are also validated, typically after the project backlog or iteration backlog is updated.

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, expect some consolidation of stories, and expect some use (or reuse) of common functionality.

Thus, recognize that Agile may not 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.

The last thing to do is circle back to the narrative: Is the big question verified? If so: victory!
If not, back to the sponsor for guidance and direction