WriteTheUserManualFirst suggests collecting UserStory''''''s to create a UserManual. A UserStory has a different audience than a UserManual.
----
The UserManual serves the end-user, whereas a UserStory needs to serve the developer. Because the two have different audiences, they have different requirements. The UserManual is usually less specific than a UserStory needs to be, since many details about the implementation are either hidden from the user or obvious from the UserInterface. And a UserManual typically says the same thing in multiple places for clarity, for example in a ''Getting Started'' section, a tutorial section, and a reference section, each referring to the others; whereas functionality defined by a UserStory wants to be OnceAndOnlyOnce.

* I would assert that the user manual should be viewed as a formalized user story for user interface design and development. When done in an incremental manner, I can see the value in defining what data items one will group together on a screen, the order in which the data items will be presented, the order in which screens will be presented, and the operations that will be permitted on the screen. I am also assuming that one keep the user manual agile, i.e., allow the details to adjust to technical realities found during development.

* The advantage to this approach (incremental development of the user manual in conjunction with the software) is that there is minimal lag time between completing a software phase and completing the user manual for that phase. This is a great advantage when your head sales person suddenly wants to take an evaluation copy of a new feature to present to a big client.
----
I question the assumption that the User Manual and User Stories should target separate audiences. The development of software requires a dialog where the users specify what they desire and the developers specify what they can provide. The resulting software is a combination of what the users desire and what the developers can provide. With this viewpoint, what starts out as a pure user story morphs into a pure user manual with no clear dividing line between the two. This emphasizes a continuous development approach rather than a phased approach.
----
in WriteTheUserManualFirst I related a story about Danaher Controls and the way they created -- and '''printed''' -- complete user manuals long before the product was ever coded up. In their case the user manual was The Word on how the product was supposed to work. There were no user stories used to establish the instrument's operation, since every single button press had already been accounted for. Why have user stories when you don't need them? -- MartySchrader