> 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?)
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.
I get a feeling that it doesn't really matter which way you go (only that your
mileage may vary...), as long as you are comfortable with the route.
Different people on this list do it differently, and all feel comfotable, and
agile...
I think it's most important to know that there are many good approach to select
from, when your setting out on the road.
>
>> For example: User Interfaces and maybe also non-functional requirements,
>> that is interfacing to some function, can be expressed in the
>> "user-story-exapnded-to-a-use-case."
> Use Cases and Stories aren't subsets of each other. The critical
> forces with a Story from the developer's viewpoint are that they
> can be estimated (which means that the developers know how
> they're going to implement it) and that they fit within one iteration
> comfortably.
> Non-functional requirements are stories as well: they're stories
> that are marked "Constraint" and have to be considered for
> each and every other story. They may generate actual implementation
> stories of their own, but by themselves they're not something you
> can schedule.
> Stories like "security" and "internationalization" have the same
> impact on use cases: they have to be considered in each use
> case; they can't be cleanly abstracted.
> The same thing is true of user interfaces. "Polish the order
> entry screen until it shines" is something that your GUI guy
> can probably estimate once the functional requirements for
> that screen are in place, especially if development has already
> put together something that has the required functionality.
> In other words, it's a good story, but it's not something
> that I'd put into a use case.
> Use cases are very good for the abstract UI (the application
> layer). They simply don't do very much for the concrete
> UI (the GUI or whatever.)
I got my copy of "User Stories Applied" and now I got this issue explained very
good from two different sources.
Thanks a lot!
> John Roth
/Mattias
[Non-text portions of this message have been removed]
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/
