I got smacked down in Jerry's class today because Jerry said
"the scrum master and business owner collaborate through a common interface of business and technical knowledge..."
i suggested
"what about using what xp calls the system metaphor"
He responded paraphrased, "Business owners won't get that tech stuff"
... like a metaphor is techie... I think anyone who's taken Comp I knows what a metaphor is.
That aside, Jerry gave us a great presentation of agility that was very user story and collaboration centric so for that I give his custom adaptation of xp, scrum, and crystal clear a huge 2 thumbs up.
What i really learned is how to collaborate unit and acceptance testing. I do not know if everyone else in the room came away with this same thought, but I look at it like this:
If i'm writing on the back of a card ideas or objectives of 'things to test'. Or reminders. Then "Who does the testing" is irrelavent. It's more contextual than that.
For some things, i may write some unit tests.
Maybe I'll do some manual tests.
Maybe i'll do a UI Script/automation.
Let's take a look at it more closely... Let's say i have this 'user story"
As a customer I want to purchase an order with a credit card.
As a developer, i'm going to have to write the following functions and test them:
"Purchase" - test card input, validation, and verification of the sale.
"Add Product to Order" - test that i can add and remove products from the order
"Get list of products" - test that i can retrieve products from my source of data.
As far as acceptance testing... i may want to smoke test the UI to make sure i see the list of products and that the flow works properly... but i won't need to test cards because the developer has already done unit tests that do that.
Fact is, when testing... everyone is responsible for testing... including the business owner. Everyone should realize what is being tested and what is NOT being tested and WHY and agree to it!
That's what i came away with and am very excited to see it put into play.