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.

  • are you wondering about creating a user story to create system documentation, or using a user story as the documentation of the system?
    – Ryathal
    Jan 6 '12 at 17:52
  • I think others already provided the answer you are looking for, but in general almost any work that your team does is a story. Although they are called "user" stories, they can be entered from a point of view (or need) of any stakeholder of a project, which also includes you, the developer (e.g. "As a developer, I need ..... bunch of internals....")
    – DXM
    Jan 6 '12 at 18:23
  • 2
    If you can complete and get paid for a user story without writing any code, jump all over that.
    – JeffO
    Jan 6 '12 at 18:24
  • 1
    @JeffO - I would much rather write code thanks. Maybe I can write the code to write the documentation... Sort of a Light Von Neumann machine :p Jan 6 '12 at 19:55

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

  • 6
    Operators, Administrators and other technical folks are first-class users. They get user stories just like every other user.
    – S.Lott
    Jan 6 '12 at 19:22

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.

  • 3
    If documentation is needed, eventually it can become part of the definition of done.
    – Hugo
    Jan 8 '12 at 13:11

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.