I'll comment on your questions below.
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.
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.
--- In email@example.com, Chuck <chuck-lists2@...> wrote:
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.)
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!
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
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: