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

Help on defining user stories

Expand Messages
  • David Winslow
    Our company is in the process of implementing extreme programming core practices. Sorry for the newbie questions. We have fleshed out the bare essentials for
    Message 1 of 5 , Feb 28, 2005
    • 0 Attachment
      Our company is in the process of implementing extreme programming core
      practices. Sorry for the newbie questions.
      We have fleshed out the bare essentials for what needs to be developed for a
      our reservation system. Below is the user stories that we came up with as a
      starting point. We need to actually get the details from the customer but we
      want to do this demo app the xp way first to fully understand what to put
      into the story cards.

      Could anybody please comment on the stories we have written and let us know
      if we need to do it differently. Also how do you tie up the task cards and
      customer tests to below index cards ?

      Thanks in advance,

      David





      Story 1:
      Booking inquiry

      First step in making a booking is to inquire the following:

      No of people to stay
      Date
      Type of rooms wanted

      System should display the rooms there is available and if booking can be
      made
      +- 2 days should be listed if specific date is not available
      Estimate: 2 units

      ================================
      Story 2: Configure property information

      Add information to the system which pertains to the property. This
      information will be used as headers and footers on reports and for display
      purposes within the system.

      Areas for information would be

      Property address details
      Banking details
      Logo and image details
      Property name
      Directions
      No of rooms etc

      This information should be able to edit at any time from within the system

      Estimate: 2 unit
      ==================================
      User story: Configure Room Rates

      When a room is added to the system rates needs to be defined for a year
      ahead (covering all seasons)
      This is done by the user assigning an amount to a each season with has been
      defined for a year. Like below

      Name Rate type season Rate per night
      Room 1 weeend holdiday 100

      Estimate: 3 units
      =================================
      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
      ==================================

      User story: 4 Configure seasons

      A year is divided into seasons. How the year is divided is up to the hotel
      manager.
      System should allow for user to be able to add/edit/delete seasons. They
      must cover a full year. A season should have a start date and a end date.
      Season should also have a name.

      Estimate : 1 unit

      ==================================

      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.

      Estimate : 2 units

      ===================================
      User story: 5
      Insert guest payment into System

      When a payment is received from a Guest, information needs to be entered
      into the system. A payment will be made against a outstanding balance on a
      booking. A booking is associated with a Account.
      Paid amount you be equal or less than the balance outstanding.

      Estimate: 1 unit
      ===================================
      User story: 6
      Making a booking

      To make a booking a user must insert
      guest details,
      room details,
      stay details,
      payment details

      After this has been entered a confirmation email,fax must be sent.
      Room(s) should now be booked and status should be reserved

      Estimate: 4 units


      =======================================
      User story: 7
      Print Invoice
      Once a booking is confirmed and guest have left a invoice should be printed.
      This invoice should be based on the details in The specific account

      Estimate: 2 units
    • William Wake
      ... David - I d normally think of the customer as the one owning the stories; it sounds like you re creating them for them. ... I ll give you some suggestions
      Message 2 of 5 , Feb 28, 2005
      • 0 Attachment
        On Mon, 28 Feb 2005 12:34:58 +0200, David Winslow <david@...> wrote:
        >
        > Our company is in the process of implementing extreme programming core
        > practices. Sorry for the newbie questions.
        > We have fleshed out the bare essentials for what needs to be developed for a
        > our reservation system. Below is the user stories that we came up with as a
        > starting point. We need to actually get the details from the customer but we
        > want to do this demo app the xp way first to fully understand what to put
        > into the story cards.

        David -
        I'd normally think of the customer as the one owning the stories; it
        sounds like you're creating them for them.

        > Could anybody please comment on the stories we have written and let us know
        > if we need to do it differently.

        I'll give you some suggestions but the important thing is to start
        small and pay attention to the feedback from what happens.

        > Also how do you tie up the task cards and
        > customer tests to below index cards ?
        Not quite sure what the question is here. Usually I just put tasks on
        a white board:
        Story title
        -task
        -task
        -task

        I'll usually organize customer tests by story.


        > Story 1: Booking inquiry
        > Estimate: 2 units

        (Are your units essentially like days or like weeks? I'd keep them
        smaller if possible. You might try real-time estimates and see how
        that feels.)

        > Story 2: Configure property information
        > User story: Configure Room Rates
        > User story: 3 Configure Rooms for Desktop application.
        > User story: 4 Configure seasons
        > User story: 5 Create an Account for A booking
        > User story: 5 Insert guest payment into System

        > User story: 6 Making a booking
        >
        > To make a booking a user must insert
        > guest details,
        > room details,
        > stay details,
        > payment details
        >
        > After this has been entered a confirmation email,fax must be sent.
        > Room(s) should now be booked and status should be reserved
        >
        > Estimate: 4 units

        I would have expected this to be the first or second story. It seems
        like the essence of the system to me, but it's got a bunch of other
        stories as prerequisites. The other stories don't really stand alone
        (in terms of utility to a customer).

        So I'd look to trim this story down to the essence. That to me would
        be something like "Room #. Date. Customer info." No confirmation. (I'd
        make those separate stories.) I'd probably make the first story not
        worry about pricing (though that might be the very next story).

        For the first version, I'd strip out everything people could look up
        by hand. (For example, the chart of season versus room cost.)

        This story has one of the bigger estimates. I'd try to strip down
        until I had a small estimate.

        > User story: 7 Print Invoice

        Good luck!
        --
        Bill Wake William.Wake@... www.xp123.com
      • Michael Dubakov
        I think your stories are pretty good. They re quite general and descriptive, they re have estimate and they re independent (as I understand them) and they re
        Message 3 of 5 , Feb 28, 2005
        • 0 Attachment
          I think your stories are pretty good. They're quite general and
          descriptive, they're have estimate and they're independent (as I
          understand them) and they're have business value. BV is not expressed
          though, and maybe it will be better to assign Business Value on each
          user story. Something like that:

          Story 1:
          Booking inquiry
          ...
          +- 2 days should be listed if specific date is not available
          Estimate: 2 units
          Business Value: Great

          > Also how do you tie up the task cards and customer tests to below
          index cards ?

          We use our own software (TargetProcess:Suite) to bind User Stories and
          Tasks together. We did not use index cards because of the remote team
          members.

          Michael
          http://www.targetprocess.com
          XP Planning Tool

          --- In extremeprogramming@yahoogroups.com, "David Winslow"
          <david@w...> wrote:
          > Our company is in the process of implementing extreme programming core
          > practices. Sorry for the newbie questions.
          > We have fleshed out the bare essentials for what needs to be
          developed for a
          > our reservation system. Below is the user stories that we came up
          with as a
          > starting point. We need to actually get the details from the
          customer but we
          > want to do this demo app the xp way first to fully understand what
          to put
          > into the story cards.
          >
          > Could anybody please comment on the stories we have written and let
          us know
          > if we need to do it differently. Also how do you tie up the task
          cards and
          > customer tests to below index cards ?
          >
          > Thanks in advance,
          >
          > David
          >
          >
          >
          >
          >
          > Story 1:
          > Booking inquiry
          >
          > First step in making a booking is to inquire the following:
          >
          > No of people to stay
          > Date
          > Type of rooms wanted
          >
          > System should display the rooms there is available and if booking can be
          > made
          > +- 2 days should be listed if specific date is not available
          > Estimate: 2 units
          >
          > ================================
          > Story 2: Configure property information
          >
          > Add information to the system which pertains to the property. This
          > information will be used as headers and footers on reports and for
          display
          > purposes within the system.
          >
          > Areas for information would be
          >
          > Property address details
          > Banking details
          > Logo and image details
          > Property name
          > Directions
          > No of rooms etc
          >
          > This information should be able to edit at any time from within the
          system
          >
          > Estimate: 2 unit
          > ==================================
          > User story: Configure Room Rates
          >
          > When a room is added to the system rates needs to be defined for a year
          > ahead (covering all seasons)
          > This is done by the user assigning an amount to a each season with
          has been
          > defined for a year. Like below
          >
          > Name Rate type season Rate per night
          > Room 1 weeend holdiday 100
          >
          > Estimate: 3 units
          > =================================
          > 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
          > ==================================
          >
          > User story: 4 Configure seasons
          >
          > A year is divided into seasons. How the year is divided is up to the
          hotel
          > manager.
          > System should allow for user to be able to add/edit/delete seasons. They
          > must cover a full year. A season should have a start date and a end
          date.
          > Season should also have a name.
          >
          > Estimate : 1 unit
          >
          > ==================================
          >
          > 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.
          >
          > Estimate : 2 units
          >
          > ===================================
          > User story: 5
          > Insert guest payment into System
          >
          > When a payment is received from a Guest, information needs to be entered
          > into the system. A payment will be made against a outstanding
          balance on a
          > booking. A booking is associated with a Account.
          > Paid amount you be equal or less than the balance outstanding.
          >
          > Estimate: 1 unit
          > ===================================
          > User story: 6
          > Making a booking
          >
          > To make a booking a user must insert
          > guest details,
          > room details,
          > stay details,
          > payment details
          >
          > After this has been entered a confirmation email,fax must be sent.
          > Room(s) should now be booked and status should be reserved
          >
          > Estimate: 4 units
          >
          >
          > =======================================
          > User story: 7
          > Print Invoice
          > Once a booking is confirmed and guest have left a invoice should be
          printed.
          > This invoice should be based on the details in The specific account
          >
          > Estimate: 2 units
        • William Pietri
          ... 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
          Message 4 of 5 , Feb 28, 2005
          • 0 Attachment
            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@...>
          • 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 5 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.