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

RE: [XP] Help on defining user stories

Expand Messages
  • David Winslow
    Thanks so much for the feedback. I will incorporate all the great points into the next version. I am already learning a lot which is great!! We are meeting
    Message 1 of 5 , Mar 1, 2005
    • 0 Attachment
      Thanks so much for the feedback. I will incorporate all the great points
      into the next version. I am already learning a lot which is great!! We are
      meeting with the client in a few days to flesh out the *real* stories and
      will keep you posted on the outcome. Thanks again.

      Regards,

      David

      -----Original Message-----
      From: William Pietri [mailto:william@...]
      Sent: Tuesday, March 01, 2005 9:29 AM
      To: extremeprogramming@yahoogroups.com
      Subject: Re: [XP] Help on defining user stories


      On Mon, 2005-02-28 at 12:34 +0200, David Winslow wrote:
      > Could anybody please comment on the stories we have written and let us
      know
      > if we need to do it differently.

      Hi, David! It looks like you've made a good start. I agree heartily
      with most of Bill Wake's comments, and won't duplicate them. Below,
      somewhat randomly organized, are my suggestions. Feel free to ask if you
      have more questions.


      My first comment is about user focus, and applies to almost all of your
      stories. For example, in your first story, you write:

      > Story 1:
      > Booking inquiry
      > [...]
      >
      > System should display the rooms there is available [...]

      Here you don't mention anything about the human involved. Although you
      probably have it in mind, I think it's very important to make clear what
      humans a feature is for, rather than to talk in abstract system
      capabilities. I'd rewrite this one as "Desk clerk searches for available
      rooms."

      Unless, of course, you have a different user in mind. I could imagine
      that you'd want different interfaces for desk clerks, telephone
      operators, and customers. And perhaps special interfaces for, say, the
      person who helps book blocks of rooms for wedding parties or
      conferences. By making it explicit that you're thinking of the desk
      clerk, you may inspire your Customer to suggest other cards for people
      you haven't even heard of.

      To help everybody think about the roles, one technique that can work
      well is Personas, where you create imaginary people that represent
      different sorts of users.



      You didn't mention the expected size of your points, but some of these
      stories look a little large to me. If you expect a story to take more
      than a few days, you should probably break it up. For example, take this
      story:

      > User story: 3 Configure Rooms for Desktop application.
      >
      > Setup Hotel rooms so they can be booked in the desktop system. Following
      > information needs to be available:
      > Room ID
      > Room type
      > Rate schema (see config of room rates)
      >
      > Configure Rooms for Web application.
      > Same as above but with following details more:
      > Room description
      > Room pictures
      > Amenities
      > RoomID

      There are two obvious stories there. And I'd also make pictures a story
      on its own. Several times I've had product managers say that pictures
      were absolutely vital right up until the moment we estimated the card.


      One story puzzles me:

      > User story: 5 Create an Account for A booking
      > This account will be utilized for creating the invoice for the stay and
      > could include dinner phone calls and mini bar expenses.

      This seems to describe an internal detail of the system. If this is
      something a user has to do manually, you should mention which user does
      it. Otherwise, the work should be part of some card where it has a
      visible effect. E.g., "Data entry clerk enters minibar charges from
      housekeeping inventory sheet."


      I also note that a number of things don't seem connected. For example,
      there's a story for printing an invoice, but there's no story for
      checking out. You mention that this is a demo, so I'm presuming that's
      why. But once you do this for real, your stories should, when put
      together, really tell a story. E.g.,

      * Guest searches for available rooms via web.
      * Guest books room via web.
      * Guest pays reservation deposit via American Express.
      * System sends guest their reservation confirmation email.
      * Desk clerk checks reserved guest in.
      * Housekeeping enters minibar charges.
      * System imports call charges from PBX.
      * Desk clerk extends guest's reservation.
      * Room service charges room for meals.
      * Desk clerk checks guest out.
      * Desk clerk charges guest's on-file credit card.
      * Desk clerk prints invoice for guest.
      * System sends electronic coupon and survey to departed guest.

      Does that makes sense? By organizing your work in terms of little
      stories that help tell bigger stories, you can take advantage of all the
      experience people have with narratives.


      Best of luck with your demo,

      William


      --
      William Pietri <william@...>



      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com
      Yahoo! Groups Links
    Your message has been successfully submitted and would be delivered to recipients shortly.