I've been told "User Stories are not requirements, it is just a reminder of what customer wants, you cannot put requirements within a story". But let's take for an example that a customer wants a different processing for different credit cards. There are strict requirements that must be implemented and known so that test cases can be written. Where should requirements go if not in the user story?
How can developers develop from a story if there are no lower requirements? How testers can write test cases (detailed ones) based on a user story? Where to requirements like DB constraints, fields validation etc. live outside of the user story?
Best Answer
This answer will focus on how to work with User Stories and lower level requirements. I won't be discussing the virtues, or lack thereof, of Scrum or Agile. I won't be talking about gurus either.
This answer assumes you're on board with Scrum but haven't yet found a way to make it work for you.
As others have mentioned, User Stories are meant to cover how the Users would like the software to be. Because the Users don't care about low level implementation stuff like database tables, constraints, architectural patterns, etc, you won't find such details in a User Story.
However, that doesn't mean these details should not be recorded anywhere.
When developers implement User Stories they need to be aware of lower level details typical Users won't know. This information can come from SMEs, BAs, the Product Owner, your architect, or any other expert or technically minded person.
Does this mean low level details should be recorded in User Stories? No (and yes).
At some point between the time the story is created and implemented somebody will need to work out how to implement it. This usually takes the form of conversations with the people involved in the Story (User, architect, developer, etc). These conversations should result in unambiguous Acceptance Criteria which clearly delineate the scope of the User Story's implementation. These details will need to be recorded somewhere and where that is is really up to you. The key here is that these details are elicited after the User Story has been created. I think this is what your guru is trying to emphasise.
As a developer it is clear that you'll need a way to associate more specific requirements with your User Story. Just how you do that is entirely up to your team.
If people on your team want to keep these details out of the User Stories then you may need to respect that. There are benefits to keeping your high level User Stories free of implementation details. It keeps them lean and your backlog can be read as a history of what your Users and Product Owner wanted. Just make your needs as a developer known as well. You should be able to work out a compromise where simply linking to the User Story keeps everyone happy.