Our company is currently using Jira Agile to manage user stories/tasks in two-week sprints. However, there are business deliverables that also need to be completed (e.g. install guide, internal FAQ, etc). These deliverables don't necessarily need to be completed inside a sprint so we don't know if we should just add them as tasks and include as part of the software iterations.
Curious as to how other PMs/companies are handling this?
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.
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.
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:
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.
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:
If the work is expected to be completed by the sprint team, you will want to add it took the sprint.
If you add the work to the sprint and it's a fairly large task then: [1] Don't add story points and roll the task until it is completed (not my preferred solution) [2] Break it up so that the work can fit into the sprint
However, if the work is NOT to be completed by the sprint team, setup a separate rapid board to manage those tasks independently. I would advise having the tasks visible in both backlogs with the 2nd backlog filtering for just those specific issues.
This sounds like it might be a good opportunity to utilize a Kanban board if you are less concerned about tracking the time spent, don't want to break up tasks, and deadlines are less rigid.
If you can really deliver those things (install guide, FAQ, and so on) separately from the features, then in your position I would treat that as a downstream (and optional!) project. The software feature mechanism produces features as before, and the documentation project takes those features as input and produces documentation. I would manage them as completely separate pipelines.
Of course, we run a risk here of moving back in the direction of Waterfall-style phases if we're not careful. This only works if the documentation project is completely optional. If features need documentation in order to deliver value, then do not split this work into two projects! Instead, work to integrate producing documentation into the story.
I'm basing this advice on the assumption that your documentation provides an optional added value to the software features, and that, in an emergency, you have the option of diverting investment away from the documentation project and onto the software feature delivery project. If you find yourself in this situation, then the capacity that you invest in the documentation project can act as slack for the software feature delivery project. You would do well to reserve that capacity (keep people working on documentation) so that you have it available to deal with spikes in demand for software delivery work.
