At the beginning of a new agile project I often recognize that the process of creating User Stories needs to be improved. In this cases User Stories are being created 'on the fly' i.e. when they are needed during the current Sprint. This is not very efficient.
Also very important aspects of influencing the progress of the agile project proactively are ignored.
The most important aspect is to have a product backlog in place which is filled with a lot of User Stories. Scrum builds on the product backlog because it is the tool for the Product Owner to control the process of creating a product related to the needs of the customer. Not only from the functional point of view but also related to be competitive. The product owner always rearranges to User Stories based on the requirements of the customer(s).
The question is
'How can a Product Backlog be created with well-defined User Stories?'
Story Mapping is the appropriate tool to achieve this:
A big picture helps communicate effectively with users, it helps everyone involved avoid building unnecessary features, and it provides an orientation for a coherent user experience. Right from the beginning, stories were supposed to spark conversations. If you really want to come up with effective software to support an activity, then you need to look to those who build software as a vital source of ideas for its capabilities, because it’s programmers who know best what software can do. Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users' needs. A programmer who understands story mapping can better see the broader user context and can participate in framing the software— leading to a better job.
Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process—which is the most critical part of software development itself. (Martin Fowler)