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.
  • Nothing in your user story actually requires a physical printer. Why can't the implementation be a PDF file, an email, or some other implementation that can be completed within the current iteration? The context of your story (the third line) only requires a proof of purchase, not a physical receipt. – Todd A. Jacobs Nov 4 at 18:06
  • 1
    @ToddA.Jacobs Should the acceptance criterias clarify or hint if it is physically printed, pdf or email? – Siim Haas Nov 4 at 19:40
  • 2
    Testable criteria should specify how a story will be evaluated. How else would you know the work is really done? However, the criteria should only specify things that actually matter, and not over-constrain the solution space. If you truly need a physical receipt, then your story ought mention that and explain why in the context. A story isn't a specification, but it should capture the reason a given feature is being requested. Your current story doesn't define a need that could only be met with a paper receipt. – Todd A. Jacobs Nov 5 at 14:32
  • To be honest, it sounds like the story is either written incorrectly (and should be refactored), or there's a conversation that needs to happen with the Product Owner or end users to better understand the need and to agree on a solution. As written, the question currently makes it sound like the team is guessing, and creating dependencies that may or may not really be necessary. – Todd A. Jacobs Nov 5 at 14:35
up vote 11 down vote accepted

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.

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.

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.