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?

One of the biggest challenges for any new agile team, in my opinion, is learning how to break work into sufficiently small pieces that the work can be completed in an iteration. You’ll have to find the patterns that work specifically for your domain and application. I do have some general advice in one chapter in the Agile Estimating and Planning book. Beyond that, though, I can point out two common patterns I’ve seen for a team with ETL (Extract, Transform, Load) work:

• One story per data source. Stories to merge data from multiple sources are common. Those can be done a data source at a time. So, the first story is to pull data from, say, the payroll system and get it in the right format. That “right format” won’t be useful to anyone yet because it may be xml with empty data where another data source needs to provide data, etc. In the next iteration, start reading the other data source, merge it in, and output it. In the 3rd iteration, pull in let’s say the final data source and code any conflict resolution necessary between say data from the second and third sources. So that’s one example.
• Leave out error cases in the first iteration. In this approach we assume that there will be no conflicting data (each health care patient matches up to one insurance card record, for example). Generate an output file that will be in the right format (for the most part) but that won’t yet be fully usable because it may have duplicates or out of range values, etc.

I’m sure neither of these fits perfectly with your scenario but hopefully they provide insights into what will work. The more the team works through, the easier the rest get.

Good luck