Hi, Charles. It seems to me that everything you do in code must have some effect on behavior(visual or not) or data. Your PO should be aware of that after all product backlog items are her call in the end.
So, IMHO, the effect checking approach, through any means, like unit/functional/integration tests, manual or automated, formal proof, etc, could be a valuable way to achieve acceptance, by showing her the expected effects linking to the generated business value of the item implementation. The implementation details, most of the time(audit sessions usually needs code inspection) should be simply delegated and trusted to the team, i presume.
On Sun, Dec 27, 2009 at 6:49 PM, Charles <chuck-lists2@...>
I'm struggling with this. How do you convince the non technical PO that you've faithfully and accurately translated the PO's high level Acceptance Tests (aka Conditions of Satisfaction, XP "Confirmation") into automated tests (might be a mix of unit, integration, GUI, etc tests)?
Further, if your automated tests act as an "executable specification", how do you go back X sprints later and look at a feature and extract how that feature was supposed to operate?