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

Re: [agile-usability] user stories - are they mini fixed scope contracts? was...

Expand Messages
  • PaulOldfield1@aol.com
    (responding to Robin) I ve just picked out two bits of your posting... ... These both have a whiff about them of problems with the conversation part of
    Message 1 of 2 , Aug 2, 2006
    • 0 Attachment
      (responding to Robin)
       
      I've just picked out two bits of your posting...
       
      > One of the key issues faced by many teams is creating well
      > written user stories. It can be difficult to clearly describe
      the
      > problem without invoking some solution in describing the
      feature.
       
      > Usability changes seem to arrive in two ways: - as part of a
      > user story (initial spec), or as customer feedback (iterative).
       
      These both have a whiff about them of problems with the
      'conversation' part of "Card, Conversation, Confirmation".  In the
      first case there might be an over-reliance on the 'card'.  There
      might not; that's for someone closer to the context to judge.
      The card should be a placeholder for the conversation; one
      should not need to do much more than identify the problem
      so we all know what conversation needs to take place.
       
      In the second case, there seems to be no allowance for changes
      in usability to arise as part of the conversation.  Maybe this isn't
      a problem because of the connotations of the word 'changes' in
      this context - perhaps usability requirements arise during the
      conversation that are not regarded as 'changes'.  Again, it would
      take somebody closer to the context to judge.
       
      Paul Oldfield
    • William Pietri
      ... Absolutely. One of my clients is just adopting the planning game. They had a painful experience last week where the developer worked for a few days from
      Message 2 of 2 , Aug 2, 2006
      • 0 Attachment
        PaulOldfield1@... wrote:
        > The card should be a placeholder for the conversation; one
        > should not need to do much more than identify the problem
        > so we all know what conversation needs to take place.


        Absolutely. One of my clients is just adopting the planning game. They
        had a painful experience last week where the developer worked for a few
        days from some notes on a card; on Thursday they discovered that he went
        in the wrong direction, and some of his work needed to be scrapped.

        They are having a hard time accepting that the solution to "not enough
        information on the card" is to put *less* information on the card, not
        more. They'll get there, but it's a struggle.

        William
      Your message has been successfully submitted and would be delivered to recipients shortly.