NO.
OK I'll expand on that answer. User stories are not a requirement for being agile. And just because you write user stories doesn't mean you ARE agile. If you're just getting started, writing user stories is a great way to have better conversation and shared understanding of the problem that needs to be solved for the user. Writing user stories in the format: As a <user>, I want <something> so that <why> is a great way to get in the habit of thinking from a user's perspective.
There's also more than one way to write user stories. For instance, job stories and hypothesis driven development work just as well. Job stories follow this format: when [situation] I want to [motivation] so I can [expected outcome]. Sometimes just using a different format for the work can help drive the right conversation and solution. Hypothesis driven development looks something like this: We believe [this capability] will result in [this outcome] and we will know we've succeeded when [we see this measurable signal]. Regardless of which type or mixture of types works best for you, the formats themselves are intended to help by providing guardrails. Once you're in that habit you can remove the training wheels. The user story as a tool was never intended to be the end goal.
User stories are not the goal
The point of a user story is to get some sort of value to the user through collaboration and conversation. The goal is NOT to write a great story in the prescribed format. So many teams lose their way by focusing on writing "good" stories rather than articulating what valuable thing the user needs or what problem they are trying to solve. It should also be said that not everything can or should be forced into user story format. Writing bugs or tasks in user story form isn't very useful. You should write those however you need to in order to fix the bug or complete the task.
When we focus our stories or requirements on articulating the problem to be solved from the user's perspective rather than following a format, we will realize more value than just going through the motions of writing "good stories" by the book. If you think about the stories in your backlog as placeholders for conversations you'll be way better off than a list of perfectly written user stories that are no different than an extensive requirements document.
If you find yourself getting hung up on writing good user stories, try a different story format or try having the conversation that's meant to be had in order to better understand what's needed and why. Write down what you need to from the conversation. There are more important aspects of the story than just adhering to the format.
