I am just getting into user stories (read some blogs and watched some of Mike Cohn's presentations).
My current understanding is that the story is a vertical slice of the system. Stories are not "Add database so that customer's data is permanently stored" or something horizontally similar.
Stories are about "What" instead of "How".
Now the project/product that I'm working with can be thought as a vending machine. So let's say I have the following story in the project called "vending machine":
As a customer,
I want to receive a receipt,
so that I can prove my purchase later.
This story seems to depend strongly on the printer that can physically print a receipt, but let's say that development has been kicked off but hardware hasn't arrived yet.
I can write business logic and GUI, but I cannot integrate with the printer.
However, I can create an implementation that would "print" receipt to console output.
Is it ok to extract task out of this story and consider the story to be done?
The task would be something like:
"Create xerox printer implementation for [Printer] interface"
This can potentially mean that all the stories can be completed before hardware arrives, but it leaves us with a bunch of (concrete) tasks.
On the one hand, it feels OK, if Product Owner (or whoever accepts the story) understands and accepts that constraint/compromise.
Yet, it can be said
"How come you say that you have completed the story, but you cannot demo it?".
"[Hardware arrives]. Well, the hardware is here. Install our software and let's ship it.
-No, we need 2 weeks for integration.".
All in all, it seems to come down communication (second 'C' in the card, conversation, and confirmation) and common understanding (confirmation).
My concern is that I'm new into this and this is a first and so far only idea how to approach this situation and experience shows that following blindly through initial ideas can lead to dark corners.
I have accepted @Sarov's answer, but I would like to leave what I have learned from this thread:
- Multiple answers and comments brought to my attention that (done) stories should provide value. "How" shouldn't matter.
- @Todd A Jacobs points out that the story can be flawed since the value can be delivered without having an external dependency.