Well, maybe it says "As a product manager I want my system to incorporate an ecommerce server so that I can collect money."
Can you get that done this iteration? It sounds like a three-story-point effort to me, right?
Hold On A Second
This story doesn't have a plot. It is a state of being. I don't think that saying "once upon a time there was a little girl" would qualify me as a story teller.
Right away I'm nervous. What the heck does it mean? What do we want to do here?
Let's not throw this into the sprint backlog with (of all things) a story point number on it. Let's certainly not stick somebody's name on it. Let's think a little.
We're not aligned on what this "story" means.
The New Preplanning Poker
You already know about planning poker, and the benefits of silently estimating first, then comparing results. You know that it helps avoid anchoring and arguing and lets you see the degree of separation in estimates in the team. It's a nice consensus-seeking idea.
I think we need to apply that concept forward to pre-planning (and to non-estimating teams). We will need five cards for this new preplanning poker, as follows:
The astute among you might notice that the acronym for this set of cards accidentally spells DARES. I guess that's okay if we're trying to determine whether we dare tackle this feature as given.
All you really need is five index cards per person and a marker, but if you really want something you can cut and print, try these (font is bubblegum sans):
So here is the story. Pick one of the cards, don't show its face. Ready? One... two.. three
You picked defer. Why is this not a good time to add this feature? Why is later better? Is there something far more important to do? Too few developers and testers available this week? Is it scheduling? Availability of people? Is there a dependency such that it would be very hard now, but another feature will soon finish after which this one is easy to complete?
You picked accept. You think that this task is very well-defined and the criteria for success are obvious. You're ready to go, and you know how to do the work. I'm shocked, given the nature of the story but tell us what you know and what inspires your enthusiasm.
You picked reject. You don't think that the system needs an eCommerce system? Why? Do you have another way you'd rather we received money? Do you think this system should not receive money? Do you think that we should use this system in a way other than a money-gathering device? Why should we never do this?
You picked explore. You think it's a good idea, and we should get involved, but you believe that there are technical issues involved that we don't understand. Is it platforms? Licensing? APIs? Languages? Authorization/Authentication issues? Architectural concerns? Dependencies? What do we need to know in order to move forward? I think you are likely right - this may not be something you simply bolt on without some exploration of vendors and technologies and market segments.
You picked split. That means that this story is not really scoped well. Maybe it needs to be rewritten as a series of stories, or a series of releases, so that each increment of this feature will be well-understood and can be tested and possibly documented. In this case, I agree with you. We might need to know who needs to pay, and for what, and what the flow is around each payment scenario. Each point of payment will likely need several stories to cover all the ways it can succeed or fail.
Will It Work?
I have played this game without cards at a few client sites. Sometimes I'm surprised at how vague a story can seem to me, but be perfectly clear to the local development team. Other times I'm surprised in the opposite way.
We have had great story mapping and story splitting sessions result from these quick 5-way triage games (is that a quintage?) It takes only minutes and you can get a lot of focused discussion and backlog grooming done in a very short time.
If you try it out, let me know how it worked for you.