Post History

Source: https://writers.stackexchange.com/a/12442
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

I've written manuals under a Scrum process, so I'll describe what worked for my team.

I'm going to treat your task as if you're writing a new book. From your description, you'd be replacing the vast majority of the content anyway, so better to think of it as a new book (for which you might be able to take advantage of the occasional previously-written bit) than an update.

First you're going to need to come up with an outline or broad plan of attack. What topics do you need to cover (in what detail)? Is the organization of the original book workable now, or do you need to re-arrange things? In (or prior to!) your first sprint, come up with your initial list of work to be done. Start thinking about how it breaks down into stories. (This is the initial backlog; you should expect to discover more things that will need to be covered as sprints progress. Use your usual process for managing those; in our case newly-discovered issues got added to the backlog and considered in the next planning session.)

During sprint planning, you (plural) should identify which of these tasks to work on now -- due to urgency, or code stability, or whatever other criteria are at play in your team.

During each sprint you should be working on the following types of tasks:

- Writing new material (scoped to fit the sprint, less the other work you need to do in this sprint)

- Addressing feedback from what you wrote in the last sprint (you should be getting feedback from developers, testers, and user representatives as you go)

- Updating prior work for changes in the code, if applicable -- if you're working on the doc alongside the developers working on the code, there are probably going to be changes that you'll need to address

During the last couple of sprints before the release, start thinking about what will need to go into the release notes. I assume that the release notes are a team project, as they usually include things like a bug list from QA. Your part of this is to identify what is important enough to document that isn't going to make it into the user guide, and then figure out how to address that in release notes. This should result in a story for your last sprint, with the team agreeing on the tasks to be included.

(I should mention that on my last agile team the release notes were actually managed by the QA team, not by the technical writers, so my advice on that point is based on what I've seen/heard others do, not on direct personal experience.)

Original score: 6