Suppose the client wants to build an online shopping system. If we think of use case scenario, a database or a bank would be a secondary actors to this system.

Is it valid to have a user story like

 As a customer I want to be able to access the database so that I can view catalog items


As a customer, I want to access the bank so that I can pay by credit card.

I think the above does not seem valid, but please advise, as I am very new to this field. Thanks

2 Answers 2


User stories generally don't include implementation details. They aim to capture the functionality the user is looking for:

As a customer, I want to be able to view the catalog of items for sale

As a customer, I want to be able to pay with a credit card

Note that these make no mention of databases, banks, APIs, connection details, or anything else. How you implement that functionality is up to you (the developer), as you could possibly store all your items for sale in text files, one file per item, and there is no database to speak of.

Now, of course, your PO can (and should!) put some additional details, requirements, acceptance criteria to give you a better idea of what they have in mind, and to keep the story from being too broad and vague.

As a customer, I want to be able to view the catalog of items for sale, including filtering by category. I want to be able to view thumbnail images of the items along with name and short description, in some kind of list.


As a customer, I want to be able to pay by credit card and save it for future order. I want to input my card number again if a new address is used, in order to combat fraud. I don't want to have to select which type of card is being used.

Whether you put the items into a ListView or a DataGridView or an HTML thing or some custom thing you wrote in Python, doesn't matter - as long as the functionality is provided.

How you store the credit card info, the customer doesn't care (local privacy laws notwithstanding, of course). They just want to be able to pay with a credit card, and not have click a radio button indicating whether it's a Visa, MC, AmEx, Discover, etc.

Note that implementing these stories may very well depend on those secondary actors you mentioned (database, bank). If you do indeed store your catalog in a database, then you (as the developer, not the customer) will need some way to retrieve information about those items. Or you'll need a way to interface with a credit card processing company to process card payments. If you don't already have those set up, they may simply be a task in one of these stories. Or they may become additional user stories or spikes:

As a developer, I need a way to interface with the CC processing company, so we can submit payments. Outcome should be a prototype program which can send request for payment and receive response.

I said stories generally don't include implementation details, but there are of course exceptions, with this being one (although it still makes no mention of actual implementation). Invariably, you will need to define stories to set up your environment, research various bits, etc, and those will be more technical / specific and contain implementations.


Assuming these stories are for developer/engineer. Can we frame it this way -

"As a engineer, I want to provide an interface to the customer to access catalog items from the database."

  • Based on my understanding, I assume it is wrong to think of user stories from point of view of the engineer or developer. It should only be the client or end users, etc
    – Melanie A
    Feb 1, 2019 at 16:55
  • It is reasonable to have a user story for an internal customer support person, do something like, "As customer support, I want to be able to review customer transactions with the customer when they call." Feb 1, 2019 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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