Re: [scrumdevelopment] Re: Complex Story splitting: Part 2
- View SourceI'm new to this list so apologies if my comments mirror those made previously by others.
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.
Sure, Let's start one!
I almost feel like we need a 'UserStories' list on yahoogroups. :-)
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.
Charles --- In email@example.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.)
Not by my definition of orthodoxy. But maybe I'm not orthodox ;-)
My next set of questions: --------------------------------- So, in conclusion, I have some questions:: a) Did I do anything unorthodox here?
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.
b) Did I lose some value or create risk by doing it this way
instead of say, the wordsmithing approach?
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
Preface: 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 shopping. ----------- 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.
Overview: 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:
If 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: http://groups.yahoo.com/group/scrumdevelopment/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/scrumdevelopment/join (Yahoo! ID required) <*> To change settings via email: mailto:firstname.lastname@example.org mailto:email@example.com <*> To unsubscribe from this group, send an email to: firstname.lastname@example.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
-- 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