In brief, they are comparable notions, while agile techniques often use a related concept called the User Story. If you're following SCRUM by the book, I advocate doing exactly what SCRUM advises because your team will expect it. If not, there's nothing wrong with employing Use Cases in an agile context; I've done it dozens of times over the last two decades.
A Use Case is nothing more than a list of functional requirements (steps, flows). User Stories seek to do the same thing, describing a set of actions in the process.Both are frequently developed in stages, beginning with a name, objective statement, statement of key actors, and so on, and then expanding on steps and flows, triggers, pre and post conditions, and so on as more information becomes available. There are other organised approaches to communicate functional needs, such as UML activity diagrams and BPMN processes, that you might want to examine. What I like about Use Cases is that you can start with a diagram ("blobs on a page") and graphically explain their relationships with other use cases, actors, and, if you're at that level, the system boundary. You can also use a formal tool for modelling Use Cases (there are many, just google it).Both of these characteristics are difficult to do in Epics and User Stories, which frequently begin as post-it notes on a kanban or a collection of seemingly unrelated "as a...blar... I need to..." assertions. As a result, even if you decide to elaborate as User Stories, I propose using a Use Case diagram to define scope and conduct your initial research, with each Use Case ultimately being a User Story.
