I was asked recently how to go about writing user stories for a back-end financial system. This is an interesting example and is a question I get asked a lot, so I thought I should answer it here. This example brings up a couple of key interesting challenges:
- While there may be users of the system they are not often not direct users (i.e., with hands on the keyboard waiting for something to happen)
- The functionality is often larger than will fit in one iteration
So that we can deal with these challenges, let’s make up some more context for the example. Suppose our financial system takes in a lot of daily data and produces flat files that will be sent to banks and other partners at the end of the day. Some of the files are simple formats. Other files are in more involved formats with multiple record types within the file and possibly with multiple lines for some of the transactions. This would be a fairly standard batch-processing type application.
I want to write user stories in the template I recommend in the book: As a , I want so that . So, let’s deal with these challenges in order and first try to figure out who the user will be in our stories? Given the context provided above the user, is probably a bank or business partner. This will let us write stories like “As a bank, I want…” It’s entirely possible that we will want to get more specific and sometimes write stories for more specific users:
- As a commercial bank, I want….
- As a savings & loan, I want…
- As the Bank of America, I want… (assuming we have some specific business partnership that provides BofA with unique functionality)
Now, what is it these banks want?
At a high level we can start out with some epics, perhaps like these:
- As a bank, I want to receive a file showing all checks to be cleared so that I can debit and credit the right accounts.
- As a bank, I want to receive a correctly formatted 5300 file so that I can adjust balances as appropriate.
- As a bank, I want to receive a file showing the status of all resubmitted transactions so that I can update the database with new information.
(Note that I am liberally making up specific business rules or details. Presumably someone writing the real user stories could add real and relevant detail instead.)
First, notice it is OK to humanize the bank with “As a bank, I want…” Programmers do this all the time in conversation. “OK, suppose I’m the bank and you send me a 5300 file with a bad record. In that case, I’ll…”
As I said at the start of this post, one of the challenges in an application like this is that some of these user stories we just made up could be large. Suppose our mythical file format 5300 includes a header, three different record types, and a footer. We could break up the 5300 file user story above into things like:
- As a bank, I want to receive a 5300 file with the correct header and footer so that I can process the file correctly.
- As a bank, I want to receive a 5300 file with correctly formatted prearranged payment records so that I can process those correctly.
- As a bank, I want to receive a 5300 file with correctly formatted deposit entry records so that I can process them.
- As a bank, I want to receive a 5300 file with correctly formatted addendum records so that I can process them.
If those were still too big, I would find ways to split them smaller based on the specific formatting of the records. Suppose our deposit entry record type sometimes fits on one line but can also span multiple lines. In that case I could write these user stories:
- As a bank, I want to receive a 5300 file with correctly formatted single-line deposit entry records so that I can process them.
- 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.
Is the system “potentially shippable” after each of these user stories is delivered? Yes, it kind of is. While I’ll admit that we’re unlikely to find a bank that will take a 5300 file with only a header and a footer, it’s possible. Especially if we think of the situation in which the bank is simultaneously writing their own software to process the 5300 files we send them. Imagine meeting with the bank before the start of the next iteration and perhaps agreeing, “OK, in this iteration we’ll create some blank 5300 files with just headers and footers. But that will let us make sure that the communication problems are worked out, that you can read the files we write, and so on….” These stories also work well because they will likely fit with how the programmers will want to build the system.
Tags: agile requirements, user stories
Mike:
Thanks for taking the time to write this out. It is this flexibility that makes User Stories such a potent tool in the Agilist’s kit. This is why some of us are able to ply the trade outside the world of software, computers, and technology – moving into the realm of architecture, ‘real’ engineering, and other places where empirical approaches meld creativity to complex delivery.
Thanks for the examples Mike – examples of stories for back-end functionality are less common than UI stories, but I, at least, spend a lot of my time with back-end functionality.
It’s good to remember that a customer can be another system or partner – this is fairly common in use case modeling, where every partner system becomes an actor, but somehow when you’re thinking of customers it doesn’t seem as natural. But thinking of a customer as whoever gains benefit from the story makes this easier.
In addition to outputting correctly formatted records, another common issue with batch files is outputting the correct records – all of today’s transactions, or only the credits from a certain source for today. For these stories I’ve tried to separate the format from the selection of the records, in part because they are often worked on by different developers. The database person handles the query to find the correct records, while someone else works on the Velocity template to format each field properly. And they can be tied together with an epic story.
Another common feature for these types of stories is the need to refer to another document for all of the file format details. Sometimes it’s tempting to try to recreate all of the formatting rules in stories, but it’s much easier, and less error-prone, to simply refer to or attach the file specification provided by the partner system.
Another issue is how to best write automated tests for batch files – but that’s probably a topic for another post.
Hi Kevin–Great additions. Yes, selecting the records could be additional stories: “As a bank, I want to receive a file with only the last 7 days of data”, for example. Scheduling could be an additional story: “As a bank, I want the 5300 file transferred between midnight and 1am each night.”
Last summer I worked with a bank to help set up a SOA platform and a whole slew of services, none of the work actually touched an end-user. Most of these services were really just wrappers to host transactions. While we didn’t follow the “as a bank, I want XXX” for user stories, we did break up our services and other components into release and iteration plans (a la estimation and planning) which were then accompanied by a brief paragraph of text.
We treated presentation layer developer leads and enterprise architects as the clients who would review these “stories” at the end of the iteration. Certainly user stories can be successful as long as you are flexible when considering who your users can be. Probably why like the term stakeholders better, and often use another term for user stories depending on the project.
This is great – I’ll be pointing a few people to read this as I’m struggling to get this out of an integration partner right now.
The subject got me wondering; are there teams who define the UI in user stories and then use some other template for back end? Why would anyone do this? I’m aware that in some teams there is pressure to keep the number of personas or actors down to a minimum (without apparent rationale) – surely its better to comprehensively define the entire persona list necessary to get the job done (I’m referring to the Bank of America etc as personas – is that ok?).
I think its true to say that every story has a ‘customer’ and a ‘supplier’ in the broadest generic sense. So, in every story there is some entity making something happen (supplier) for the benefit of some other entity (customer). I would even be comfortable (with my anorak on) abstracting this right down to a logic statement in the code where the same applies. For example in “If x>10 then do function1 else do function2†– the condition “If x>10†is the supplier making something happen for one of two customers, function1 and function2. User story = As function1 I want to be executed when x>10 so that …
Or am I just going mad and having too much fun with this
I would expect that for most user stories the “customer” and “supplier” as you think of them are the same person. That is, I (as a user) want to do something because it pleases me (not because it pleases someone else.
Also, taking user stories so deep that they are at the level of the individual functions as you show is an interesting possibility, but I suspect it will almost always result in writing user stories that are too small to provide a good conceptual view of what is to be achieved by the story. User stories should be higher level than in your examples.
Mike – sorry my comment was misleading and I’ll concede, a little too abstract perhaps…
Yes, I agree there is only one person or group represented and they are making a statement about what will benefit them. The “supplier†I was referring to is not a person or group – it is the feature that provides (supplies) the benefit.
Although as you point out – completely impracticable – for me its helpful to consider such abstract concepts of user stories in order to work outside the box that often restricts user stories to defining UI.
Hi Dave–Thanks for the clarification. I can now more of what you meant. User stories can indeed be used for non-UI things but it is harder to wrap our heads around doing so at first.
Michael ,
because there are no actual users being talked about in the stories is the word “user stories” really applicable? Sure they can follow the same format, but I always seem to have difficulty explaining to my clients when I’m using “user” stories for backend requirements. I had to call them component stories, have you or anybody else reading this had similar experience? is it useful having the notion of different kinds of stories entering our official vocabulary?
I just call them “stories” in that case. But I can see calling them “System stories” or anything that helps my customer or product owner understand and engage in writing them.
Great post.
Speaking from the perspective of a Product Owner. I always find it interesting how difficult of a time we sometimes have making sense of the back-end functionality. The truth is, it’s likely to be delivering value to some customer/user or it wouldn’t have ended up there in the first place. I believe nearly all stories can be written from the “actual user” perspective, if we really dig into it.
To revisit one of the epics listed above:
As a bank, I want to receive a file showing the status of all resubmitted transactions so that I can update the database with new information.
Stories like this could also be presented from the user perspective:
As a Cash Manager, I want to electornically inform the bank of all resubmitted transactions so that they can efficiently track and account for all new information.
The information that’s being sent around in a system is directly or indirectly presented to some user, although perhaps in a summarized or massaged form (if that wasn’t true, then the system would just be electronic hardware chattering to itself). In that sense it’s true that all stories could be recast in a form that involves human users. However, in order to actually work with stories at the design or implementation level we’re also faced with a size constraints on stories, and insisting that all stories go back to reference the end user directly often times makes ‘back end’ stories too large to deal with (which was more or less the point of Mike’s article). As a Product Owner you may not care much about the size of stories, but other people on the team do.
Wow! Did I sense a bit of a shot at the end there : ) I absolutely care about the size of the stories. While it is clear that many encounter product owners who don’t see beyond their own role, I can assure you I understand the value of collaborating with and understanding the needs of the team.
Perhaps my reply didn’t come across in the way I had intended. It definitely wasn’t meant to “insist” anything. I was actually agreeing with Mike’s point that there are users beyond those who directly work with the system and suggesting that we are all best served by helping the team to understand and have some visibility into this. I feel that Product Owners who don’t do their best to define back-end functionality in this way are the ones doing their teams a disservice.
If there is a collaborative way for the product owner and team to arrive at the “right-sized” stories, rather than anyone rushing to slice it up from some perspective not aligned with actual usage or business value, I’d suggest that would be preferable. I’ve rarely encountered a situation that couldn’t be broken down in this way.
Please note, I said “nearly all stories” in my original reply and “rarely” above… Of course, I am always open to arriving at the right answer for the team, based on the context of any given situation.
We have a Scrum team that works on ETL-type stories. They are struggling with slicing up the stories to fit their sprints, which are already 3 weeks long. They tend to look at it as “all-or-nothing”, i.e. it doesn’t make sense to them to just do a portion of the requested ETL functionality. More often than not, this leads to stories spanning sprints or “Scrummerfall” (QA is done in a subsequent sprint). Any specific ideas on how ETL stories could be carved up in a better way?
Hi Rene–
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:
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
It looks like we are ‘trying to fit’ into the format. This is far from the real life and looks very artificial. I have seen people writing user stories like ‘as an architect I want to write a method to compress the file’ etc.. Whole agile paradigm is revolving around consulting (trainings to certify people, writing books etc) while the real value addition is still questionable. I have seen one leading consultant joking about another consultant (I don’t know what he was smoking while he was writing that book..)
HELP!!
I work with the ultimate back-end system: a TCP/IP stack. Our user story is an application that sends a request to it’s local TCP/IP stack asking for information about the connection partner. The application is our “end user” and we can verify the request sent from the application and the response returned to the application. The tasks involved are (1) stackA receives the request, (2) creates a message to send to stackB, (3) sends the message, (4) stackB receives the message, (5) stackB processes message, (6) stackB creates a message to send back to stackA, (7) sends the message, (8) stackA receives the message, (9) stackA creates the response, (10) stackA sends response to the application.
Sending the request and receiving the reply is just a small part of the overall function to be shipped. It will take well over 4 weeks (our sprint size) to code and test with code being the major effort. It is of no shippable value on its own, but we can define it as a function. We will unit test the request/response flow at each stage but will not function test until the request provides a response. If we create user stories for each small step defined above I think we will be breaking the rule “do not turn user stories into tasks”. We view code and unit test as a “coding” effort. Should we change our view? Should we create user stories for each step above and be content that UT is the “tested” function? And have function verification as a task only in the last step? We tried convincing the team to break it down into the steps above, but they pushed back because there is nothing to functionally test at those boundaries. We have ended up with a user story much bigger than a sprint.
I am anxious to hear your opinion on this! Thanks.
Hi Mike,
I have some additional questions re this excellent thread about technical stories using the banking system as an example.
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?
Hi Robert–
Lots of questions; I’ll do best my best to answer all. Hopefully others chime in with opinions here as well.
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.
I’m currently in a situation where the major part of the application being built is a rather complex algorithm that in itself will likely take months to figure out and validate.
The user of the system will invoke this algorithm and see a result but there are very few real user stories of the “As a I Want” format where there is true user interaction. The users goal is to see the result of the algorithm.
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?
Hi Robert-
Yes, absolutely. Use the ways you can see now to split the big algorithm story into smaller pieces. This prevents a team from “going dark” on the customer, gives them a regular sense of progress, and keeps urgency on an otherwise long task. Good luck.
Mike,
In one of the presentations on your site you showed an example of a user story along the lines of “As the XYZ System I need an API to ”
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?
Robert–
Definitely not. But sometimes teams communicate with each other through their product backlogs. That’s the only time I’d expect to see this. I’d equate it to yelling, “Hey, Joe, don’t forget to add something so I can delete boojums from the database this sprint.” And, yes, this would almost always be written by a team member rather than a product owner.