----- Original Message ----- From: "Mattias Vannerg�rd" <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Sent: Wednesday, December 29, 2004 8:24 AM Subject: SV: [XP] User Stories and 'the Big Picture'
> > >> The User Story doesn't matter unless you need a historical record. >> What does matter is the Executable Acceptance Tests, which are >> what the user story becomes. Ron frequently puts this process as >> Card, Conversation, Confirmation. > > Great! > And the confirmation should be Re-executable. Like regressiontesting? > I'm still intrested in where the Conversation is stored (does it always > fit on the story card?) It gets included in the Executable Acceptance Test. That's one of the nice things about using FIT/FitNesse - since the EAT is simply an HTML document, you can include anything you want in it. That typically includes enough explanatory text to clarify what the tables do, but it can also include links to other documents, etc. If you're really into bureaucracy (and some teams have to be to meet regulatory requirements) you can put other things into it, like traceability information. That's a trick I'll expand on if you're interested. The proper approach could also let you generate your use case documentation from the Executable Acceptance Tests. > Don't you technically elaborate on the Conversation-part? (My idea was > expanding the story card into a use case, see below) > >>> Agreed, and the design space is spanned with user stories in their >>> simplest form. >>> >>> And, therefore I like to keep them. >>> >>> I like also to think in terms of expanding the User Stories into Use >>> Cases, to capture the interesting design issues. > >> It's possible to see many of the Executable Acceptance Tests >> as being scenarios from a use case. In fact, that's what I'd >> recommend if you take a Use Case approach: write one or >> more Executable Acceptance Tests for each scenario. (Note >> that I don't recommend taking a Use Case approach - that's >> a local decision that may be appropriate for some projects >> and not for others. This is simply what I recommend if you >> decide to use Use Cases to pull things together.) > > Mike Cohn and Martin Fowler seem to think that its good to take a Use > Case-approach and extract User Stories from it. One thing that isn't very clear in a lot of what gets written about use cases and XP is that you need to split the use case into two parts: the "Essential Use Case" and the scenarios. The essential use case is everything that isn't in the scenarios: it should fit on one page, and you can write it in one shot. The scenarios should be developed incrementally: there's no particular reason you want to do them up front. Of course, use cases cascade, and you might need to do some of the scenarios in order to motivate lower level use cases. That's especially true of use cases that are "in the clouds" to use Alistar Cockburn's terms. They need to be expanded to get the sea level use cases, which is where the customer side meets the development side. The Poppendiecks refer to this in: http://www.poppendieck.com/pdfs/Agile_Customers_Toolkit_Paper.pdf It's the best single document I've seen on the customer side of the process. > > I got my copy of "User Stories Applied" and now I got this issue explained > very good from two different sources. > > Thanks a lot! You're welcome. John Roth > >> John Roth > > /Mattias To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
