Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Writing User Stories the 5Ws way

Expand Messages
  • John A. De Goes
    Hi Craig, I m not arguing that conversation is not important. I m arguing only that the power of the written word should not be underestimated. If a customer
    Message 1 of 50 , Apr 18, 2008
    • 0 Attachment
      Hi Craig,

      I'm not arguing that conversation is not important. I'm arguing only
      that the power of the written word should not be underestimated. If a
      customer writes a description of a user-interface on a card, then the
      customer will expect the user-interface to look as written --
      conversation be damned.

      In general, I think, the clearer you can be about the responsibility
      of the customer, the better your outcome. Forcing the customer to
      convey goals and motivations explicitly defines (and limits) the scope
      of the customer's responsibility. It gives you the flexibility you
      need without creating false expectations in the mind of the customer.

      That said, what you have been doing appears to be working fine for
      you. The above just reflects my experience as a contractor.

      Regards,

      John A. De Goes
      N-BRAIN, Inc.
      http://www.n-brain.net
      [n minds are better than n-1]

      On Mar 30, 2008, at 11:42 AM, Craig Davidson wrote:

      > Hi John,
      > No probs on the 37signals stuff. They've influenced my work a lot
      > over the
      > last few years, both in their approach and their web framework.
      >
      > You wrote:
      > > You can write a blank story with nothing on it. According to what
      > > you've just told me, that isn't a bad way to write a story. If so,
      > why
      > > write user stories at all?
      >
      > Card's are not stories, just the marker for the story.
      > Er, you could use a blank card, but only if there is only one story,
      > it
      > which point using cards become irrelevant.
      > Fundamentally though, I don't want customers to write stories, I
      > want them
      > to tell stories.
      >
      > > A good story distills an unmet need for the end-user. It explains
      > in a
      > > single sentence some goal the user has, and explains why the user
      > > wants to accomplish that goal.
      > My understanding is that the text on the card is just a marker, the
      > conversation is the important bit.
      >
      > > A template I've seen somewhere on the web reads, "As a XXX, I want
      > to
      > > YYY, so that I can ZZZ." For example, "As a student, I want to
      > comment
      > > on the instructor's blog postings, so I can make my opinion known to
      > > others." This is a good user story.
      >
      > As text on a card it is fine. But it's not a complete story...
      > It's missing the conversation and confirmation aspects.
      >
      > > It's concise and to the point,
      > > forms a good starting point for conversations,
      > So is "student comments", etc, etc.
      > I'm happy (within reason) with whatever the customer feels is the best
      > prompt to for them to remember what they wanted to get across.
      > The card's job is just to get us to the conversation at around the
      > appropriate time for the priority as arranged in planning games.
      >
      > > does not create false
      > > promises in the mind of the customer, is easily and unambiguously
      > > translated to acceptance tests, and contains rich meaning that
      > enables
      > > the development team to leverage their skills at user-interface
      > design.
      >
      > Did you deduce just from the text on the card?
      >
      > I wouldn't want to risk that. I'd rather have the conversation.
      > That's why I'm not bothered about what is written on the card.
      > If the customers conversation is full of user interface stuff, I
      > want to
      > hear that and I want to understand why?
      > I wouldn't want to dismiss it out of hand before giving them the
      > courtesy of
      > listening to them.
      >
      > Cheers,
      >
      > Craig
      >
      > On 30/03/2008, John A. De Goes <john@...> wrote:
      > >
      > >
      > > Hi Craig,
      > >
      > > You can write a blank story with nothing on it. According to what
      > > you've just told me, that isn't a bad way to write a story. If so,
      > why
      > > write user stories at all?
      > >
      > > Similarly, I've seen users write 'stories' that approximate
      > > requirement specification documents. Are you *really* sure you
      > want to
      > > come down on the side that says these stories are as good as any
      > other?
      > >
      > > A good story distills an unmet need for the end-user. It explains
      > in a
      > > single sentence some goal the user has, and explains why the user
      > > wants to accomplish that goal.
      > >
      > > A template I've seen somewhere on the web reads, "As a XXX, I want
      > to
      > > YYY, so that I can ZZZ." For example, "As a student, I want to
      > comment
      > > on the instructor's blog postings, so I can make my opinion known to
      > > others." This is a good user story. It's concise and to the point,
      > > forms a good starting point for conversations, does not create false
      > > promises in the mind of the customer, is easily and unambiguously
      > > translated to acceptance tests, and contains rich meaning that
      > enables
      > > the development team to leverage their skills at user-interface
      > design.
      > >
      > > From some of the things you wrote, it seems you have jumped into
      > this
      > > conversation in the middle. I never suggested it was possible to get
      > > great user interfaces on the first attempt. Instead, I recommended
      > an
      > > iterative approach based on usability testing, with the first
      > > iteration crafted by the usability expert.
      > >
      > > When possible, 'eating your own dog food' is a valuable part of
      > > developing usable software, but it's a rather small part of the
      > > overall picture. It cannot replace usability testing -- and does
      > not,
      > > even at Fog Creek Software, which performs and advocates extensive
      > one-
      > > way mirror usability testing (which is why their products are such a
      > > joy to use). Both of these practices, combined with getting to know
      > > the market of your product and the mind of your end-user, increase
      > the
      > > chances of producing a great user interface. Where usability theory
      > > comes in is explaining the underlying cognitive reasons why some
      > > interfaces are great, and why others are horrible; in giving you the
      > > conceptual tools for creating great user interfaces; and in enabling
      > > that first draft to be very close to the target, thus reducing the
      > > number of revisions.
      > >
      > > I took a look at the book you mentioned by 37signals. I'm amazed by
      > > how much their philosophy is similar to my own; from the emphasis on
      > > usability, to just saying no to features, to the attitude that
      > > 'preferences are bugs, not features' (my words not theirs). Thanks
      > for
      > > the recommendation.
      > >
      > > Regards,
      > >
      > > John A. De Goes
      > > N-BRAIN, Inc.
      > > http://www.n-brain.net
      > > [n minds are better than n-1]
      > >
      > > On Mar 30, 2008, at 1:12 AM, Craig Davidson wrote:
      > >
      > > > Hi John,
      > > >
      > > > You wrote:
      > > > --
      > > > However, you can't talk a good user interface out of an end-
      > user, no
      > > > matter how hard you try (unless the end-user happens to be a
      > usability
      > > > expert).
      > > > --<snip>
      > > > there are good ways to write user stories and there are bad ways.
      > > > You can mitigate the effects of bad
      > > > stories with constant communication with the customer, and by
      > > > clarifying that what's written on the story has little or no
      > relation
      > > > to what's going to be implemented (it's only a 'memory jogger',
      > as you
      > > > say). However, the far more direct and efficient approach is to
      > write
      > > > good stories that reflect what will be implemented.
      > > > --
      > > >
      > > > I totally disagree that there are good ways and bad ways to write
      > > > story
      > > > cards.
      > > > The only really bad way is if it the wording stops the
      > conversation
      > > > happening,
      > > > stops the "story being told" if you will.
      > > > I've seen that happen where projects become overly concerned
      > with the
      > > > wording on the card!!
      > > > I keep repeating on those projects: "the card is not the
      > requirement".
      > > >
      > > > Your statement makes me think, you practice user stories
      > differently
      > > > to me?
      > > > That is fine, I don't believe there is one true way, neither yours
      > > > nor mine.
      > > >
      > > > I also disagree that you can't talk a good user interface out of
      > an
      > > > end-user,
      > > > I've seen it happen lots of times.
      > > > no usability expert has as much at stake as someone that is
      > going to
      > > > use something every day for the next 5 years.
      > > > Iterative is the key word for me, I don't believe you get good
      > > > interface
      > > > first time, keep re-doing it until it is good.
      > > > Form does not always follow function - as Donald Norman said,
      > pretty
      > > > things
      > > > work better.
      > > >
      > > > For me "dogfooding" is the best usability testing (
      > > > http://www.joelonsoftware.com/articles/fog0000000012.html).
      > > > Either the customer or the developers should be doing it. Ideally
      > > > both.
      > > > And whoever is, is probably best placed for establishing further
      > UI
      > > > requirements.
      > > >
      > > > I suggest you have a look the "Interface first" chapter of the
      > > > Getting Real
      > > > process by
      > > > 37Signals (http://gettingreal.37signals.com/ch09_Interface_First.php
      > ).
      > > > They have been for a long time now attempting to fuse the
      > useability
      > > > work of
      > > > Cooper with Extreme Programming practices.
      > > > And as I see they are one of the most (the most?) successful and
      > > > productive
      > > > companies practicing agile software development today.
      > > >
      > > > Cheers,
      > > >
      > > > Craig
      > > >
      > > > On 30/03/2008, John A. De Goes <john@...> wrote:
      > > > >
      > > > >
      > > > > Hi Chris,
      > > > >
      > > > > On Mar 29, 2008, at 4:41 PM, Chris Wheeler wrote:
      > > > > > On Sat, Mar 29, 2008 at 2:17 PM, John A. De Goes <john@n-
      > > > brain.net>
      > > > > > wrote:
      > > > > > > What I have strongly argued for is that user stories -- as
      > > > submitted
      > > > > > > to the development team by the customer -- should not
      > contain
      > > > any
      > > > > > > description of the user interface. They should be written
      > at a
      > > > very
      > > > > > > high level that preserves as much information as possible
      > > > about what
      > > > > > > the user wants to do and why she wants to do it. The depth
      > and
      > > > > > > richness in this information permits a greater degree of
      > > > > > collaboration
      > > > > > > and can leverage the skills of the development team at
      > creating
      > > > > > highly
      > > > > > > usable interfaces that meet the needs of the end-users. It
      > also
      > > > > > > enables the development team to get inside the mind of the
      > end-
      > > > user,
      > > > > >
      > > > > > One way to get into the mind of the end-user is to talk to
      > the end
      > > > > > user. I
      > > > > > guess the question is, do you always do exactly as what's
      > > > written on
      > > > > > the
      > > > > > story card, or do you talk to the customer all the way
      > through the
      > > > > > development of the story? Really, if you do that, it doesn't
      > > > matter
      > > > > > what the
      > > > > > user writes on the card.
      > > > > >
      > > > >
      > > > > A couple of points here:
      > > > >
      > > > > 1. Like you say, talking to the end-user is very helpful.
      > Getting to
      > > > > know the challenges they face, how they're currently solving
      > those
      > > > > challenges, and even how they would like to solve them, is
      > > > invaluable.
      > > > > However, you can't talk a good user interface out of an end-
      > user, no
      > > > > matter how hard you try (unless the end-user happens to be a
      > > > usability
      > > > > expert).
      > > > >
      > > > > 2. Remember the customer is *not* usually the end-user. You
      > seem to
      > > > > conflate the two in the above paragraph. Talking to the
      > customer all
      > > > > the way through the development of the story will not (by
      > itself)
      > > > > produce a great user interface.
      > > > >
      > > > > 3. It does matter what the customer writes on the card, partly
      > > > because
      > > > > the card forms an implicit contract with the customer (made
      > explicit
      > > > > when acceptance tests are derived from the card), and partly
      > because
      > > > > it is the primary source of information for estimation and
      > feature
      > > > > development.
      > > > >
      > > > > If a customer writes a description of a user interface on a
      > card,
      > > > then
      > > > > the customer will expect to see that interface in the next
      > > > iteration.
      > > > > [1] Moreover, a description of an interface is at such a low
      > level,
      > > > > goals and motivations are no longer readily apparent.
      > Consequently,
      > > > > the development team has no choice but to proceed with
      > whatever the
      > > > > customer has concocted -- end-user be damned.
      > > > >
      > > > > Of course, you can always talk with the customer to gather more
      > > > > information, so let me be clearer: there are good ways to
      > write user
      > > > > stories and there are bad ways. You can mitigate the effects
      > of bad
      > > > > stories with constant communication with the customer, and by
      > > > > clarifying that what's written on the story has little or no
      > > > relation
      > > > > to what's going to be implemented (it's only a 'memory
      > jogger', as
      > > > you
      > > > > say). However, the far more direct and efficient approach is to
      > > > write
      > > > > good stories that reflect what will be implemented. Stories that
      > > > > encode maximal information, in the form of goals and
      > motivations.
      > > > > Stories that give the development team the ability to leverage
      > their
      > > > > usability skills. Stories that can easily and unambiguously be
      > > > > translated into acceptance criteria in the form of usability
      > tests.
      > > > >
      > > > > > A story is simply a promise to have a future conversation, a
      > > > memory
      > > > > > jogger,
      > > > > > so to speak. It can contain anything that helps jog memory and
      > > > start
      > > > > > conversations. Even UI descriptions.
      > > > > >
      > > > >
      > > > > It can also be 500 pages long and detail exactly how every
      > aspect of
      > > > > the application should work. That doesn't mean using such
      > > > 'stories' is
      > > > > a good way to develop great software.
      > > > >
      > > > > Regards,
      > > > >
      > > > > John A. De Goes
      > > > > N-BRAIN, Inc.
      > > > > http://www.n-brain.net
      > > > > [n minds are better than n-1]
      > > > >
      > > > > [1] Of course, you can explain to the customer you won't be
      > > > > implementing that interface, but after doing this a few times,
      > the
      > > > > customer will become very frustrated.
      > > > >
      > > > >
      > > > > ------------------------------------
      > > > >
      > > > > To Post a message, send it to: extremeprogramming@...
      > > > >
      > > > > To Unsubscribe, send a blank message to:
      > > > > extremeprogramming-unsubscribe@...
      > > > >
      > > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
      > > > >
      > > > >
      > > > >
      > > > >
      > > >
      > > > [Non-text portions of this message have been removed]
      > > >
      > > >
      > > >
      > >
      > >
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      > > ------------------------------------
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.comYahoo! Groups Links
      > >
      > >
      > >
      > >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >



      [Non-text portions of this message have been removed]
    • John A. De Goes
      Hi Craig, I m not arguing that conversation is not important. I m arguing only that the power of the written word should not be underestimated. If a customer
      Message 50 of 50 , Apr 18, 2008
      • 0 Attachment
        Hi Craig,

        I'm not arguing that conversation is not important. I'm arguing only
        that the power of the written word should not be underestimated. If a
        customer writes a description of a user-interface on a card, then the
        customer will expect the user-interface to look as written --
        conversation be damned.

        In general, I think, the clearer you can be about the responsibility
        of the customer, the better your outcome. Forcing the customer to
        convey goals and motivations explicitly defines (and limits) the scope
        of the customer's responsibility. It gives you the flexibility you
        need without creating false expectations in the mind of the customer.

        That said, what you have been doing appears to be working fine for
        you. The above just reflects my experience as a contractor.

        Regards,

        John A. De Goes
        N-BRAIN, Inc.
        http://www.n-brain.net
        [n minds are better than n-1]

        On Mar 30, 2008, at 11:42 AM, Craig Davidson wrote:

        > Hi John,
        > No probs on the 37signals stuff. They've influenced my work a lot
        > over the
        > last few years, both in their approach and their web framework.
        >
        > You wrote:
        > > You can write a blank story with nothing on it. According to what
        > > you've just told me, that isn't a bad way to write a story. If so,
        > why
        > > write user stories at all?
        >
        > Card's are not stories, just the marker for the story.
        > Er, you could use a blank card, but only if there is only one story,
        > it
        > which point using cards become irrelevant.
        > Fundamentally though, I don't want customers to write stories, I
        > want them
        > to tell stories.
        >
        > > A good story distills an unmet need for the end-user. It explains
        > in a
        > > single sentence some goal the user has, and explains why the user
        > > wants to accomplish that goal.
        > My understanding is that the text on the card is just a marker, the
        > conversation is the important bit.
        >
        > > A template I've seen somewhere on the web reads, "As a XXX, I want
        > to
        > > YYY, so that I can ZZZ." For example, "As a student, I want to
        > comment
        > > on the instructor's blog postings, so I can make my opinion known to
        > > others." This is a good user story.
        >
        > As text on a card it is fine. But it's not a complete story...
        > It's missing the conversation and confirmation aspects.
        >
        > > It's concise and to the point,
        > > forms a good starting point for conversations,
        > So is "student comments", etc, etc.
        > I'm happy (within reason) with whatever the customer feels is the best
        > prompt to for them to remember what they wanted to get across.
        > The card's job is just to get us to the conversation at around the
        > appropriate time for the priority as arranged in planning games.
        >
        > > does not create false
        > > promises in the mind of the customer, is easily and unambiguously
        > > translated to acceptance tests, and contains rich meaning that
        > enables
        > > the development team to leverage their skills at user-interface
        > design.
        >
        > Did you deduce just from the text on the card?
        >
        > I wouldn't want to risk that. I'd rather have the conversation.
        > That's why I'm not bothered about what is written on the card.
        > If the customers conversation is full of user interface stuff, I
        > want to
        > hear that and I want to understand why?
        > I wouldn't want to dismiss it out of hand before giving them the
        > courtesy of
        > listening to them.
        >
        > Cheers,
        >
        > Craig
        >
        > On 30/03/2008, John A. De Goes <john@...> wrote:
        > >
        > >
        > > Hi Craig,
        > >
        > > You can write a blank story with nothing on it. According to what
        > > you've just told me, that isn't a bad way to write a story. If so,
        > why
        > > write user stories at all?
        > >
        > > Similarly, I've seen users write 'stories' that approximate
        > > requirement specification documents. Are you *really* sure you
        > want to
        > > come down on the side that says these stories are as good as any
        > other?
        > >
        > > A good story distills an unmet need for the end-user. It explains
        > in a
        > > single sentence some goal the user has, and explains why the user
        > > wants to accomplish that goal.
        > >
        > > A template I've seen somewhere on the web reads, "As a XXX, I want
        > to
        > > YYY, so that I can ZZZ." For example, "As a student, I want to
        > comment
        > > on the instructor's blog postings, so I can make my opinion known to
        > > others." This is a good user story. It's concise and to the point,
        > > forms a good starting point for conversations, does not create false
        > > promises in the mind of the customer, is easily and unambiguously
        > > translated to acceptance tests, and contains rich meaning that
        > enables
        > > the development team to leverage their skills at user-interface
        > design.
        > >
        > > From some of the things you wrote, it seems you have jumped into
        > this
        > > conversation in the middle. I never suggested it was possible to get
        > > great user interfaces on the first attempt. Instead, I recommended
        > an
        > > iterative approach based on usability testing, with the first
        > > iteration crafted by the usability expert.
        > >
        > > When possible, 'eating your own dog food' is a valuable part of
        > > developing usable software, but it's a rather small part of the
        > > overall picture. It cannot replace usability testing -- and does
        > not,
        > > even at Fog Creek Software, which performs and advocates extensive
        > one-
        > > way mirror usability testing (which is why their products are such a
        > > joy to use). Both of these practices, combined with getting to know
        > > the market of your product and the mind of your end-user, increase
        > the
        > > chances of producing a great user interface. Where usability theory
        > > comes in is explaining the underlying cognitive reasons why some
        > > interfaces are great, and why others are horrible; in giving you the
        > > conceptual tools for creating great user interfaces; and in enabling
        > > that first draft to be very close to the target, thus reducing the
        > > number of revisions.
        > >
        > > I took a look at the book you mentioned by 37signals. I'm amazed by
        > > how much their philosophy is similar to my own; from the emphasis on
        > > usability, to just saying no to features, to the attitude that
        > > 'preferences are bugs, not features' (my words not theirs). Thanks
        > for
        > > the recommendation.
        > >
        > > Regards,
        > >
        > > John A. De Goes
        > > N-BRAIN, Inc.
        > > http://www.n-brain.net
        > > [n minds are better than n-1]
        > >
        > > On Mar 30, 2008, at 1:12 AM, Craig Davidson wrote:
        > >
        > > > Hi John,
        > > >
        > > > You wrote:
        > > > --
        > > > However, you can't talk a good user interface out of an end-
        > user, no
        > > > matter how hard you try (unless the end-user happens to be a
        > usability
        > > > expert).
        > > > --<snip>
        > > > there are good ways to write user stories and there are bad ways.
        > > > You can mitigate the effects of bad
        > > > stories with constant communication with the customer, and by
        > > > clarifying that what's written on the story has little or no
        > relation
        > > > to what's going to be implemented (it's only a 'memory jogger',
        > as you
        > > > say). However, the far more direct and efficient approach is to
        > write
        > > > good stories that reflect what will be implemented.
        > > > --
        > > >
        > > > I totally disagree that there are good ways and bad ways to write
        > > > story
        > > > cards.
        > > > The only really bad way is if it the wording stops the
        > conversation
        > > > happening,
        > > > stops the "story being told" if you will.
        > > > I've seen that happen where projects become overly concerned
        > with the
        > > > wording on the card!!
        > > > I keep repeating on those projects: "the card is not the
        > requirement".
        > > >
        > > > Your statement makes me think, you practice user stories
        > differently
        > > > to me?
        > > > That is fine, I don't believe there is one true way, neither yours
        > > > nor mine.
        > > >
        > > > I also disagree that you can't talk a good user interface out of
        > an
        > > > end-user,
        > > > I've seen it happen lots of times.
        > > > no usability expert has as much at stake as someone that is
        > going to
        > > > use something every day for the next 5 years.
        > > > Iterative is the key word for me, I don't believe you get good
        > > > interface
        > > > first time, keep re-doing it until it is good.
        > > > Form does not always follow function - as Donald Norman said,
        > pretty
        > > > things
        > > > work better.
        > > >
        > > > For me "dogfooding" is the best usability testing (
        > > > http://www.joelonsoftware.com/articles/fog0000000012.html).
        > > > Either the customer or the developers should be doing it. Ideally
        > > > both.
        > > > And whoever is, is probably best placed for establishing further
        > UI
        > > > requirements.
        > > >
        > > > I suggest you have a look the "Interface first" chapter of the
        > > > Getting Real
        > > > process by
        > > > 37Signals (http://gettingreal.37signals.com/ch09_Interface_First.php
        > ).
        > > > They have been for a long time now attempting to fuse the
        > useability
        > > > work of
        > > > Cooper with Extreme Programming practices.
        > > > And as I see they are one of the most (the most?) successful and
        > > > productive
        > > > companies practicing agile software development today.
        > > >
        > > > Cheers,
        > > >
        > > > Craig
        > > >
        > > > On 30/03/2008, John A. De Goes <john@...> wrote:
        > > > >
        > > > >
        > > > > Hi Chris,
        > > > >
        > > > > On Mar 29, 2008, at 4:41 PM, Chris Wheeler wrote:
        > > > > > On Sat, Mar 29, 2008 at 2:17 PM, John A. De Goes <john@n-
        > > > brain.net>
        > > > > > wrote:
        > > > > > > What I have strongly argued for is that user stories -- as
        > > > submitted
        > > > > > > to the development team by the customer -- should not
        > contain
        > > > any
        > > > > > > description of the user interface. They should be written
        > at a
        > > > very
        > > > > > > high level that preserves as much information as possible
        > > > about what
        > > > > > > the user wants to do and why she wants to do it. The depth
        > and
        > > > > > > richness in this information permits a greater degree of
        > > > > > collaboration
        > > > > > > and can leverage the skills of the development team at
        > creating
        > > > > > highly
        > > > > > > usable interfaces that meet the needs of the end-users. It
        > also
        > > > > > > enables the development team to get inside the mind of the
        > end-
        > > > user,
        > > > > >
        > > > > > One way to get into the mind of the end-user is to talk to
        > the end
        > > > > > user. I
        > > > > > guess the question is, do you always do exactly as what's
        > > > written on
        > > > > > the
        > > > > > story card, or do you talk to the customer all the way
        > through the
        > > > > > development of the story? Really, if you do that, it doesn't
        > > > matter
        > > > > > what the
        > > > > > user writes on the card.
        > > > > >
        > > > >
        > > > > A couple of points here:
        > > > >
        > > > > 1. Like you say, talking to the end-user is very helpful.
        > Getting to
        > > > > know the challenges they face, how they're currently solving
        > those
        > > > > challenges, and even how they would like to solve them, is
        > > > invaluable.
        > > > > However, you can't talk a good user interface out of an end-
        > user, no
        > > > > matter how hard you try (unless the end-user happens to be a
        > > > usability
        > > > > expert).
        > > > >
        > > > > 2. Remember the customer is *not* usually the end-user. You
        > seem to
        > > > > conflate the two in the above paragraph. Talking to the
        > customer all
        > > > > the way through the development of the story will not (by
        > itself)
        > > > > produce a great user interface.
        > > > >
        > > > > 3. It does matter what the customer writes on the card, partly
        > > > because
        > > > > the card forms an implicit contract with the customer (made
        > explicit
        > > > > when acceptance tests are derived from the card), and partly
        > because
        > > > > it is the primary source of information for estimation and
        > feature
        > > > > development.
        > > > >
        > > > > If a customer writes a description of a user interface on a
        > card,
        > > > then
        > > > > the customer will expect to see that interface in the next
        > > > iteration.
        > > > > [1] Moreover, a description of an interface is at such a low
        > level,
        > > > > goals and motivations are no longer readily apparent.
        > Consequently,
        > > > > the development team has no choice but to proceed with
        > whatever the
        > > > > customer has concocted -- end-user be damned.
        > > > >
        > > > > Of course, you can always talk with the customer to gather more
        > > > > information, so let me be clearer: there are good ways to
        > write user
        > > > > stories and there are bad ways. You can mitigate the effects
        > of bad
        > > > > stories with constant communication with the customer, and by
        > > > > clarifying that what's written on the story has little or no
        > > > relation
        > > > > to what's going to be implemented (it's only a 'memory
        > jogger', as
        > > > you
        > > > > say). However, the far more direct and efficient approach is to
        > > > write
        > > > > good stories that reflect what will be implemented. Stories that
        > > > > encode maximal information, in the form of goals and
        > motivations.
        > > > > Stories that give the development team the ability to leverage
        > their
        > > > > usability skills. Stories that can easily and unambiguously be
        > > > > translated into acceptance criteria in the form of usability
        > tests.
        > > > >
        > > > > > A story is simply a promise to have a future conversation, a
        > > > memory
        > > > > > jogger,
        > > > > > so to speak. It can contain anything that helps jog memory and
        > > > start
        > > > > > conversations. Even UI descriptions.
        > > > > >
        > > > >
        > > > > It can also be 500 pages long and detail exactly how every
        > aspect of
        > > > > the application should work. That doesn't mean using such
        > > > 'stories' is
        > > > > a good way to develop great software.
        > > > >
        > > > > Regards,
        > > > >
        > > > > John A. De Goes
        > > > > N-BRAIN, Inc.
        > > > > http://www.n-brain.net
        > > > > [n minds are better than n-1]
        > > > >
        > > > > [1] Of course, you can explain to the customer you won't be
        > > > > implementing that interface, but after doing this a few times,
        > the
        > > > > customer will become very frustrated.
        > > > >
        > > > >
        > > > > ------------------------------------
        > > > >
        > > > > To Post a message, send it to: extremeprogramming@...
        > > > >
        > > > > To Unsubscribe, send a blank message to:
        > > > > extremeprogramming-unsubscribe@...
        > > > >
        > > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
        > > > >
        > > > >
        > > > >
        > > > >
        > > >
        > > > [Non-text portions of this message have been removed]
        > > >
        > > >
        > > >
        > >
        > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        > >
        > > ------------------------------------
        > >
        > > To Post a message, send it to: extremeprogramming@...
        > >
        > > To Unsubscribe, send a blank message to:
        > > extremeprogramming-unsubscribe@...
        > >
        > > ad-free courtesy of objectmentor.comYahoo! Groups Links
        > >
        > >
        > >
        > >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.