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

Re: Story Question

Expand Messages
  • kevinbsmith
    ... (snip) As several others have hinted, but nobody has come out and said, that sounds like at least three stories, not just one. Now, some teams seem to like
    Message 1 of 9 , Jun 30, 2002
    • 0 Attachment
      --- In extremeprogramming@y..., "Bryan P. Glennon" wrote:
      > Suppose a team is building an accounts payable
      > system. One of the tasks associated with it is Vendor
      > Maintenance - the ability to add, edit and delete
      > vendors. I can see a user story something like this:
      > "Provide a way to allow adding, changing and deleting
      > vendors. Prevent deletion of vendors that have had
      > any activity within the previous 24 months."
      >
      > Now while that is a single user story, there are
      (snip)

      As several others have hinted, but nobody has come out
      and said, that sounds like at least three stories, not
      just one.

      Now, some teams seem to like bigger stories--perhaps
      something that might take a few weeks to complete.
      Others of us prefer "microstories", lasting at most a
      few days. Rather than breaking stories into tasks, we
      try to persuade the customer to have such small stories
      that tasks are not necessary.

      There is at least one unstated story here, too: use
      existing vendor information to complete the actual
      work. You might _think_ that you would have to have
      vendor maintenance before you could do real work with
      vendors, but you don't. You might think that you would
      at least need "add vendor" first. You don't.

      You could hard-code some vendors. Or put them in a text
      file. Your customer can tell you whether they would
      rather have "add vendor" before "generate invoice".
      Perhaps being able to add and remove vendors by editing
      a text file would be sufficient for the first few months
      of your project, and could be coded in an hour.

      Also, as someone pointed out, you may not need to
      manipulate every possible vendor field in the first
      iteration. Perhaps a vendor name is enough.

      If you slice the stories up small enough, the Customer
      can get exactly what they want first, and you can show
      continuous progress.

      Hope this helps,

      Kevin
    • ericheikkila
      I would absolutely break that up into: 1. Allow adding of vendors 2. Allow changing of vendors 3. Allow deletion of vendors 4. Prevent deletion based on rules
      Message 2 of 9 , Jul 2, 2002
      • 0 Attachment
        I would absolutely break that up into:

        1. Allow adding of vendors
        2. Allow changing of vendors
        3. Allow deletion of vendors
        4. Prevent deletion based on rules (activity prior 24 months).

        I'm not sure what you mean by:
        <start quote>
        > There is at least one unstated story here, too: use
        > existing vendor information to complete the actual
        > work. You might _think_ that you would have to have
        > vendor maintenance before you could do real work with
        > vendors, but you don't. You might think that you would
        > at least need "add vendor" first. You don't.
        <end quote>

        Unless that was in reply to something from the previous post about
        absolutely needing this before doing other work within the account
        payable system. If that's what it was, then I agree. They are not
        necessarily dependant. If the accounts payable system needed vendor
        info, that could be read in from someplace (file, constant, database)
        before any of the 'real' maintenance stuff was in place. Then you'd
        add an integration story someplace about hooking the two together (if
        need be).

        -Eric


        --- In extremeprogramming@y..., "kevinbsmith" <kevinxp@q...> wrote:
        > --- In extremeprogramming@y..., "Bryan P. Glennon" wrote:
        > > Suppose a team is building an accounts payable
        > > system. One of the tasks associated with it is Vendor
        > > Maintenance - the ability to add, edit and delete
        > > vendors. I can see a user story something like this:
        > > "Provide a way to allow adding, changing and deleting
        > > vendors. Prevent deletion of vendors that have had
        > > any activity within the previous 24 months."
        > >
        > > Now while that is a single user story, there are
        > (snip)
        >
        > As several others have hinted, but nobody has come out
        > and said, that sounds like at least three stories, not
        > just one.
        >
        > Now, some teams seem to like bigger stories--perhaps
        > something that might take a few weeks to complete.
        > Others of us prefer "microstories", lasting at most a
        > few days. Rather than breaking stories into tasks, we
        > try to persuade the customer to have such small stories
        > that tasks are not necessary.
        >
        > There is at least one unstated story here, too: use
        > existing vendor information to complete the actual
        > work. You might _think_ that you would have to have
        > vendor maintenance before you could do real work with
        > vendors, but you don't. You might think that you would
        > at least need "add vendor" first. You don't.
        >
        > You could hard-code some vendors. Or put them in a text
        > file. Your customer can tell you whether they would
        > rather have "add vendor" before "generate invoice".
        > Perhaps being able to add and remove vendors by editing
        > a text file would be sufficient for the first few months
        > of your project, and could be coded in an hour.
        >
        > Also, as someone pointed out, you may not need to
        > manipulate every possible vendor field in the first
        > iteration. Perhaps a vendor name is enough.
        >
        > If you slice the stories up small enough, the Customer
        > can get exactly what they want first, and you can show
        > continuous progress.
        >
        > Hope this helps,
        >
        > Kevin
      Your message has been successfully submitted and would be delivered to recipients shortly.