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: 
"As a user of X, I need to know how X works" seems like a legitimate user story to me. This could result in written documentation or online help.

The point isn't just code--it's meeting the users' requirements.
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.