Does documentation and fixing belong in the Product Backlog?

Hi,

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

According to the scrum guide, everything that's needed to build your product is in the backlog. Fixing is mentioned in the definition.

To me documentation is part of delivering a product, so it should be in the backlog.

In my projects we included the documentation part in the definition of done and we make a task for it in every story that requires an update in our documentation.

For things like the initial writing of a user manual, we create seperate tickets.

If by fixing you refer to errors (bugs), then, yes, absolutely - where else would fixing belong?

I've found that documentation has no place on the backlog. The guide itself doesn't include the term ("documentation")

If you're looking for a great example, here's one: Atlassian offers two good tools, one for backlog (JIRA), one for documentation (Confluence)

Jan, first of all, keep in mind, the Agile Manifesto says:

Working software over comprehensive documentation

So, there is value in documentation, so if you say "documentation", at least try to minimize the waste of too much or too elaborate documentation.

That said, if the creation of the documentation is deemed valuable, it should be delivered. You can do this by incorporating it into the Definition of Done (DoD), and/or acceptance criteria, and making sure the documentation is delivered as part of the feature or increment.

I would not advice to but it separately on the backlog, because (1) it might be deemed less valuable as other PBI's and thus resulting in documentation never being delivered and (2) since documentation could in some cases only come from the team member who actually build the feature, it is not a piece of work which can be done by any team member.

(1) is a risk, specially for the longer term, and I have even heard the term "documentation debt" used in organizations to indicate a real problem with it, (2) goes a bit against the self-organization aspect of the team.

 

Not wanting to be rude on your English, but it is not exactly clear to me if by "fixing" you mean code fixes like bugfixing, or fixing (existing) documentation. If it is about documentation, the above applies. If it is about code fixing, yes it should definitely be on the backlog! Where else should it be? Fixing bugs can be just as important (and complex and consuming) as creating new features.

Can a feature of story be really "Done" when it lacks the proper documentation?

If it is self-documenting - then yes :)

Also, consider a PBI mentioned recently on this forum - upgrading icons on a website to their more modern version. I would assume that it calls for practically no documentation...