Plan the Application's First and Subsequent Releases — Including Documentation Work

This chapter explains why documentation work must be planned into every Release from the start, rather than left until the end.

Why Documentation Must Be Planned

When documentation is not planned, it is not scheduled; when it is not scheduled, it is squeezed into the last days before deployment, or skipped. Teams then reach the documentation gate described in the chapter “Enforce ‘No Documentation, No Deployment’ for Every Release” with incomplete documentation, and either delay the Release or seek an exception. Both outcomes are avoidable. Documentation is part of the work of a Release, and it must be planned, estimated, and tracked like any other part.

Establish Documentation Work in Release Planning

For the Application’s first Release, and for every subsequent Release:

• Identify, from the Release’s scope and SDLC Path, which parts of the Application Documentation will need to be created or updated.

• Include that documentation work as explicit items in the Release plan or backlog, with owners and estimates.

• Include any outstanding documentation updates required by a template change, or still owed as a fast follower under an earlier approved exception.

• Include time for each critical stakeholder’s review.

• Treat documentation work as part of the Release’s definition of done.

Document and Share the Plan

Record documentation work in the same plan or backlog as the rest of the Release’s work, visible to everyone involved, and track it to completion alongside the code, configuration, and testing work.

Best Practice: Plan Documentation Work into Every Release

It is a best practice to both establish and document the solution for delivering documentation on time: plan the documentation work for every Release explicitly, with owners, estimates, and stakeholder reviews, and treat it as part of the Release’s definition of done.

Benefits: Planned documentation work is visible, resourced, and finished on time, so Releases reach the Production gate ready to pass rather than scrambling or seeking exceptions. It also gives leaders an honest picture of the true effort of a Release, rather than an estimate that silently excludes documentation.

Connections to Related IF4IT Practices and Inventories

The Release Management Best Practices describes Release planning. The Systems Development Lifecycle (SDLC) Best Practices describes the Planning phase.