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

Re: [XP] breaking large user story up in smaller bits

Expand Messages
  • J. B. Rainsberger
    ... You might even consider the first story capturing only the key fields (in the database primary key/foreign key sense). That allows you to capture the
    Message 1 of 9 , Dec 25, 2007
      On Dec 24, 2007, at 02:18 , David Winslow wrote:

      > We a busy scoping an application which deals with capturing,
      > submitting and
      > tracking bond applications.
      > The bond application is about 350 fields.
      > Also there is about 500 business rules associated to these fields.
      >
      > My plan of action is to split the story up like this:
      >
      > CAPTURE Main Applicant Details
      > As a Consultant I can capture valid main applicant details for a new
      > bond
      > application and save the application.
      >
      > CAPTURE Property Details
      > As a Consultant I can capture valid Property details for a new bond
      > application and save the application.
      >
      > ETC...
      >
      You might even consider the first story capturing only the key fields
      (in the database primary key/foreign key sense). That allows you to
      capture the entire record with its dependent records, even though the
      result is not business facing enough to use, you could start to use it
      for something.

      > Now my questions are:
      >
      > 1)Once I have gone through the pain for during the first user
      > story.. surely
      > the next ones will be much easier to do? How to I estimate these
      > stories ?
      >
      I don't understand why the remaining stories would be estimated any
      differently than any other story. Assuming your first story doesn't
      create dependencies among the remaining stories, you can treat them
      like any other.

      > 2)Should I include capture, validation and save functionality as one
      > story
      > or should I split them up ?
      >
      I would insist on a round trip in the very first story, otherwise
      you're splitting features by layer, and that way leads to increased
      inventory through unshippable "stories" and increased expense through
      managing dependencies among stories.

      > 3) how do I go about functional testing for above? Should i let the
      > user
      > test through the ui or should we write fitnesse tests to exercise the
      > business rules ?
      >
      Why "or"? Why not "and"?
      ----
      J. B. (Joe) Rainsberger :: http://www.jbrains.ca
      Your guide to software craftsmanship
      JUnit Recipes: Practical Methods for Programmer Testing
      2005 Gordon Pask Award for contribution Agile Software Practice
    Your message has been successfully submitted and would be delivered to recipients shortly.