In practice do you often see a story that calls on the need for a specific API? I could certainly see this as very useful for planning purposes especially if the particular API/interface/service is considered a major dependency. Again, I’d assume this class of story is usually not written by the PO. Also, this type of story seems to be very design-focused and against the general spirit of a user story. Thoughts?

As with most algorithms this one can be decomposed into parts. To manage this, would you recommend breaking this algorithm into its parts, making each part a user story and then demoing the parts as the project progresses much the same as the banking file example?

1) I wouldn’t expect the PO to write stories splitting a report story into parts about its header, footer, etc. I would expect that to come up in a discussion with the team. The team would say to the product owner that they couldn’t finish the story as written and would suggest this split.

2) Stories, even technical ones, should almost always be small enough to complete in the iteration. They may be larger early on when they are further out on the schedule horizon.

3) If I were demonstrating a story about part of the 5300 report, I’d show just that subset of the report working. If the story were something deeper in the application, I’d show what I could. Sometimes I’ve had to show nothing more than tests as you suggest.

4) The best practice here is to demo what your product owner wants to see. If the team and PO have worked together long enough, the team may just tell the PO about the story.

5) The benefit to everyone is of being able to fit these stories into a sprint rather than having them “in progress” for 3-4 sprints.

You showed 4 stories about the 5300 file which were refinements of an original story. In this thread Brad, a Product Owner (PO), discussed how he is concerned about writing right-sized stories. An excellent trait in a PO

My first comment re Brad’s statement is that many/most POs won’t know the intimate details of a 5300 file necessary to write stories like “As a bank, I want to receive a 5300 file with correctly formatted deposit entry records that include continuation lines so that I can process them.”
A PO who came from a systems engineering background at a bank might but one who is more from the marketing side likely wouldn’t.

Questions:
1. Let’s assume that the PO isn’t likely to write stories to the level of detail of the 5300 story above. Who would you think would break the story into this level of detail? What have you seen in practice?
2. In practice, do you always try to make technical stories such as this iteration sized? I’d assume yes.

Re demoing a user story, which all stories need to be … right, I’d think that the 5300 story above would, in most cases, be too detailed for many POs to appreciate in a demo. In addition, it might be difficult to demo in itself.
3. How do you typically demo stories like this to the PO? Write a test harness and show results of Fitnesse tests (for example)? What have you seen as best practice?
4. Would you even demo such a story to the PO? What have you seen as best practice?

5. It seems to me that creating technical stories to the level of detail as the above example is more for the benefit of the engineering and QA teams than the PO. It seems that its main benefit is to break complex functionality into smaller testable stories though these small stories may be of little interest to the PO, if he’s not from a technical background.
The PO may be interested from point of view of having a more well tested system but having these pieces demoed to him may be of little interest at least as compared to more user-functional stories. Agree?