Is it OK to defer implementation detail and consider user story to be done?

Question

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?".

Or:

"[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.

EDIT:
I have accepted @Sarov's answer, but I would like to leave what I have learned from this thread:

1. Multiple answers and comments brought to my attention that (done) stories should provide value. "How" shouldn't matter.
2. @Todd A Jacobs points out that the story can be flawed since the value can be delivered without having an external dependency.

Answer 1

I would say no.

As you note, user stories should be vertical slices. Another way of looking at that is that they should, by themselves, provide value.

You should only burn down stories once those stories can provide value.

However, you may be able to split and/or rework stories. As a quick example:

Recall that stories do not contain implementation details. You could, for example, accomplish your story another way - by allowing the user to enter an email, so the receipt gets emailed to them.

You would then be able to finish the first story, and create a second one:

As a customer,
I want to be able to receive a receipt without providing an email,
so that I can keep my email private.

...Which could add a secondary, 'print receipt' option.

Answer 2

Great question. It all really boils down to answering one critical question: will the minimal amount of work identified in this card still provide value? This question should be answered by the Development team and the Product Owner in tandem.

Making sure your work is independent from other work, negotiable with your Product Owner, valuable, estimate-able, small, and testable is a good model for answering the question above.

Is it ok to extract task out of this story and consider the story to be done?

^ this is a question for your Product Owner, who is responsible for maximizing the value of the work your team completes. Leaning on and refining your definition of done is equally as important as negotiating with your PO on valuable work.

In short, there is no real definitive answer to your question other than to collaborate with your Product Owner to understand and negotiate what's considered valuable. This exercise will not only help with this card, but all subsequent cards moving forward.

Answer 3

Perhaps I'm being "contrarian" when I suggest that a (true ...) "user story" ought not be expected to contain any implementation detail at all.

(After all, "your 'user' has no idea at all 'how your software works.'" And, well, you don't know everything about how your user does his/her total job, either. "And never the 'twain shall [entirely] meet.")

In my modified version of this popular methodology, "user stories are exactly that – descriptions of what actual users want to do and see." Implementation plans are produced by the team, being the only group that truly knows the software.

Implementation plans (and schedules) are drawn up entirely by the team, giving careful consideration to all of the supplied user-stories, and sometimes call for new(!) user-stories to be obtained as clarification. I don't ask or expect users to directly give me those plans in their stories. The team conceives and perfects the plans, then holds them up against the stories to see if they match, and to decide if we've done the best job that we possibly can for that user.