> 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)
Do you often look at old story cards? Or is this more a concern you have
with the theory? Personally, I rarely look at more than the last couple of
weeks of cards unless I'm trying to answer some historical question.
>> 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.
Hmmm... Depending on the definition of design, I'd probably disagree with
that. In my experience, story cards often modify previous features and
interfaces, so for many projects I don't think the current design is well
summarized with story cards.
> I like also to think in terms of expanding the User Stories into Use
> Cases, to capture the interesting design issues.
Once you've done that, what would you do with those documents?
>> 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."
Hmmm... When do you find documenting those things useful?
For user interfaces I'm generally accustomed to working them out on a
whiteboard as needed, although for web sites HTML mockups can sometimes be
nice. But those are pretty short-lived artifacts, created the week of
construction or perhaps a couple of weeks before if some user testing is
necessary. Once the UI is built, what would you use the documents for?
For non-functional requirements, I'm not sure quite what you mean. For
things like scalability, I like to turn those into functional
requirements. For more pervasive things like security, those things just
seem to be in the air, part of the team culture. Do you have examples of
non-functional requirements that agile teams would benefit from writing
down?
Thanks,
William
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/
