You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

 

The product and the documentation of the product should be in different release cycles.

A product has many components to be delivered to the customer. The documentation is one of these components. Although the documentation is often developed with the product features, it is also often difficult to get both right at the same time. How can we handle required updates to the documentation if there are no required changes to the product?

How should we deliver the product and its documentation to the customer?

Structure

The product and the documentation of the product should be in different release cycles.

The reason for this separation is that the documentation responds to different forces than the product. While it is true that a new feature probably needs also to be documented in the user guide, bug fixes do not necessarily do. Feedback from users may demand that the user guide needs to be updated to make the information easier to understand. Maybe there is an error in the documentation that is not related to the product. Therefore there are situations where the product needs to be released, but not the documentation. And on the other side, the documentation needs to be released, but not the product.

So it is beneficial to have the two release cycles separated.

Advantages

  • Independent release cycles support teams to push only updated and relevant information to the users.

Disadvantages

  • There need still be some planing to sync the documentation release with the product release. A user has no benefit from a documentation that is not in-sync with the product.

Related Practices

The following practices are related to this practice.

Name Short Description
Consider content by the frequency of change. Group content in information sets that change in the same frequency. The most important category for changes is the record, which implies no change.
Defer a decision to the last responsible moment is also a risk-reducing technique for writing documentation.
Provide views on your topic-based documentation.
  • No labels