A task doesn't have to be completed in the same Sprint as some other task to be considered project-related work. Dependencies and related work can be done in future Sprints.
100% of project-related work belongs on the Product backlog. There are no exceptions.
Decompose your documentation epics into bite-sized stories, and then prioritize those granular stories as team capacity and business priorities permit. See below for a worked example.
Supplementary Tasks Live on the Product Backlog, Too
A common misconception is that only product features belong on the Product Backlog. This is untrue. All project work must be made visible through the Product Backlog, including things like internal documentation, installation guides, and other technical writing. In Scrum, anything at all that consumes team capacity or resources should be managed the same way.
Decompose Larger Stories
Just like any other user story, if your documentation features are too large to fit within a single Sprint, decompose them. Rather than a single story that says "write an installation guide," you might have any number of smaller stories like:
- Document how to download the source tarball.
- Document how to compile the project sources.
- Document how to configure feature foo within the application.
These smaller stories can then be slotted in as team capacity and business priorities permit. A small documentation feature might fit in alongside other work, while bigger (or multiple) documentation features might need a dedicated Sprint or two. However, right-sizing the stories creates the needed flexibility to manage the work within the same framework as all other work, and to make sure that each feature is either "Done" or "Not Done" at the end of its Sprint.
Prioritize Dependencies Using the Product Backlog
In many cases, a cross-functional team will have technical writers that can write documentation while the product is being developed. This is the best-case scenario, and the goal to strive for under optimal circumstances.
However, there may be legitimate reasons why documentation can't be done until after a feature is complete. This is a dependency, which Scrum handles quite well. In such cases, the Product Owner should ensure that the documentation is prioritized for inclusion in a future Sprint once the prerequisites are completed.
Backlog items should generally be re-prioritized by the Product Owner during Backlog Refinement or Sprint Planning. The latter is perfectly fine, as it allows for dependent stories to be moved to the top of the queue, right below the list of stories that will be accepted into the current Sprint.
For example, let's say that you have six items on your Product Backlog. For this example, we'll assume that all stories are estimated at one story point each, and that your team's velocity is exactly two. During Sprint Planning, you determine that you have one or more dependencies, and that feature bar is more important right now than documentation for feature foo.
Since you can't fit three stories into the current Sprint, you prioritize (or re-prioritize) the documentation so that it is enqueued for the next Sprint. For example:
- Sprint 101 (current Sprint).
- Build feature foo.
- Build feature bar.
- Sprint 102 (next Sprint).
- Document feature foo.
- Illuminate the foo documentation with medieval calligraphy and iconography.
- Sprint 103 or later.
- Build feature baz.
- Write an FAQ for feature baz.