Is documentation a User Story?

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 1

"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.

Answer 2

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.

Answer 3

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.

Answer 4

In our organization, the tooling team, in charge of our maintaining and enhancing our continuous integration system is using Scrum to help them manage their work. They are not writing code but they are practicing Scrum nonetheless.

To answer your question specifically, I would ask if the team considers that the documentation is part of the "Definition of Done" or not.

If the team considers that the documentation is part of the "definition of done" then, there is no need for an additional story and the story cannot be accepted unless the documentation is written and validated.

If the team considers that the documentation is not part of the "definition of done", I would create a separate story so that the Product Owner can manage their work.