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

Re: [scrumdevelopment] Re: Complex Story splitting: Part 2

Expand Messages
  • Gerard Meszaros
    I m new to this list so apologies if my comments mirror those made previously by others. chuckspublicprofile wrote: Just another bump of this topic. See below
    Message 1 of 3 , Sep 23, 2008
      I'm new to this list so apologies if my comments mirror those made previously by others.

      chuckspublicprofile wrote:
      Just another bump of this topic.  See below  I'd like to assume that
      lack of objection is tacit approval, but I know better... So, for
      those playing the home game, I'd appreciate it if anyone could let me
      know if what I described below seems reasonable.  
      I'll comment on your questions below.
      I almost feel like we need a 'UserStories' list on yahoogroups.  :-)
      Sure, Let's start one!
      --- In scrumdevelopment@yahoogroups.com, Chuck <chuck-lists2@...> wrote:
      Further slicing(dicing?)  
      If I wanted to, I think I could go back and slice these stories
      further by slicing off some of the acceptance tests.  (For instance,
      in Story 2, I could slice off AT2.2-AT2.4.  In 3, I could slice off
      AT3.2-AT3.3.  In those cases, the "invitation" and "offer" would just
      degenerate to messages shown to the user as a reminder, not an actual
      option to buy immediately.)
      This is exactly what I like to do. When stories are too large, I think about the test cases they imply and look for groups of tests that could be split off into a separate story that could be implemented separately as an increment on top of the base functionality/tests.
      My next set of questions:
      So, in conclusion, I have some questions::
      a)  Did I do anything unorthodox here?
      Not by my definition of orthodoxy. But maybe I'm not orthodox ;-)
      b)  Did I lose some value or create risk by doing it this way
      instead of say, the wordsmithing approach?
      Not in my opinion. Some would argue that having smaller stories introduces risk by hiding the big picture from the team. I think we need to address this issue independently of the stories because we'll never have all the stories early in a project.

      c)  Does anyone have any further suggestions/comment?  (fyi, I love
      it when people poke holes in my theories, so brownie points to those
      of you that do!  ha ha)
      I hope other folks have gotten some value out of this, and I would
      like to thank all of those who responded and are helping me with this.
       It will help me to fight the good fight and enlighten others!
      Charles Bradley
      Denver, CO
      Original Problem  
      Assume we're talking about a generic online retail site/store that uses
      the "shopping cart" metaphor.  You browse or search for items, and you
      add them to your cart(via an "Add to Cart" button).  After every add,
      the cart displays and allows you to then proceed to checkout or keep
      ----------- Story 1:  Add Item
      Overview:  This is the simple version of the story.
      Story details:  User adds item, cart displays.
      Flowchart of Logic: 
      Formalized story:  Us a customer of the store, I want to add items
      to my cart so that I can eventually purchase them all at the same time.
      Assume this is implemented and then we move to this story/epic:
      ----------- Story/Epic 2:  Add Item with Frequent Savers Club(FSC)
      and Item Warranties.
      Story 2 is a much more complex version of the story, and while this
      story is fictional, it is pretty representative of the real life
      challenges I encountered, and it's actually simpler than the real life
      story(ugghh).  Anyway, it demonstrates a much more complex set of logic
      to describe in a User Story.
      Story details:  The site has a
      "Frequent Savers Club"(FSC) that the user can join to obtain discounts
      on merchandise.  The cost of membership is $10.  When a non club
      member/user adds an item to the cart such that the potential member
      savings for all items in the cart are a certain amount($20), we want to
      invite the user to join the club.  If they do, the FSC item is added
      (by the system)to the cart.  Then, if the original item added (such as
      a TV) has a Warranty that we can sell the user, we want to invite the
      user to purchase the warranty.  If the user accepts, the warranty item
      is added to the cart(by the system).  Once this logic completes, the
      cart displays.  To see the whole logic flow, see the flowchart below --
      the flowchart is easier to understand, although it's pretty primitive.
      Flowchart of Logic:
      Story 2 is too complex or too big to implement all at once, how would
      you recommend I break it down?   Here are some of my attempts that I
      don't like.
      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      <*> To visit your group on the web, go to:
      <*> Your email settings:
          Individual Email | Traditional
      <*> To change settings online go to:
          (Yahoo! ID required)
      <*> To change settings via email:
      <*> To unsubscribe from this group, send an email to:
      <*> Your use of Yahoo! Groups is subject to:

      Gerard Meszaros
      1-403-827-2967 or me@...
      Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code".
      Learn more at http://xunitpatterns.com/index.html
    Your message has been successfully submitted and would be delivered to recipients shortly.