Question: We need to do some user documentation for a product we have been working on for the past few sprints. We are now starting a new project in the next sprint and the PO is making the documentation for the product produced previously a User story for this sprint.

I am just wondering your opinion on this approach. Personally, I don't agree that documentation is a User Story within Scrum because it doesn't produce any code. 

EDIT: Thanks for your opinions guys. I had it in the back of my head that a sprint was to implement an increment of working software, but your views have changed my outlook. Thank you for all your answers.

Answer: 
Ideally, documentation is part of every user story and never builds up. But, in the real world, that often doesn't happen. In that case, you should create a user story for catching up on a specific missing piece of documentation.

You're right, it doesn't produce any code. But it does satisfy a user requirement and should be prioritised against other user requirements.

If this means that it never gets done, because this and that functionality is being worked on then you probably didn't need the documentation that badly.
I agree with pdr's documentation assessment if its about requirement, technical or project documentation. Ideally it should be incorporated into sprint work.

Product documentation I feel is very different as it is an actual user requested deliverable and directly provides value to the user. This should be understood of course that Product Documentation is essentially **not** a Technical Task but a Functional Task, and may or may not be a suitable activity for a technical resource on the project.

I think it should be a user story, however I feel that a project resource that has a firm understanding of the business requirements, user perspective and good technical writing skills should be assigned these tasks. Ideally this would be a business analyst if one is available, or perhaps a higher order QA tester with a firm understanding of the requirements, user stories and good technical writing skills. This could also be a developer, however product documentation written by developers tends not to be as high quality or as useful because developers usually are too close to the technical details.