In my Keeping the User in User Stories, I described the benefits of the following user story template: As a , I want so that .” In this blog entry, I want to describe how you can use the same template to address back-end functionality.
Back-end systems are those without direct users. One good example is a financial back-end system. Imagine we are creating a financial system that takes in a lot of daily data and produces 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.
One of the first things we need to do to start developing this system is to write user stories. To do that, we'll need to figure out the user for our stories. In our example situation, the user is probably a bank or business partner. This will let us write stories like “As a bank, I want…”
- 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.
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…”
Also notice that these stories are just examples. They likely would have to be broken down into smaller stories that could be completed in a sprint. And the users might have to get more specific, too:
- 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)
But my point is that the user doesn't have to be an actual person staring at a computer screen. The user can also be the entity that needs the functionality.
For more details on how to write user stories for a back-end system, you can read this blog post.
Do you want one short tip each week
from Mike to help you succeed with agile?