From: "Mattias Vannerg�rd" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
Sent: Tuesday, December 28, 2004 9:08 AM
Subject: SV: [XP] User Stories and 'the Big Picture'
>
>
>> Hi, Mattias. Ron's answer is, as usual, excellent, but I thought I'd add
>> a
>> couple of questions for you:
>
> Yep, thanks Ron!
>
>
>>> 1) Where is the "Big Picture" kept when working with stories? (see
>>> below)
>>>
>>> 2) Where do the design go?
>
>> When I read this, I wonder: which big picture? And which design?
>
> Q 1) was with the restriction that the User Story was ripped. I think my
> option right now is to not ripping the user story, but to save it if
> needed. (Maybe not needed if I still got the Big Picture in my head)
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.
>
>> For any given product, there are lots of different design representations
>> one could make, each one of which captures interesting information. And
>> before you start building, when you have a complicated branching tree of
>> potential paths through the design space, the problem is multiplied.
>
> 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.)
>
>> So which parts of the problem that you are looking to represent that
>> aren't represented by story cards?
>
> 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.)
John Roth
>
>> Thanks,
>
> Does that answer your question?
>
>> William
>
> /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
>
>
>
>
>
>
>
>
>
>
> [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 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/
