Our software product is not complete, but it is functional enough that one of our clients is using it.

We produce release notes with every sprint. The notes are divided into sections such as "New Feature", "Improvements", "Fixes" and "Known Issues".

Frequently we get a change that would never appear in the release notes of a "finished" application. Either the functionality is not complete:

  • The screens "XXX" and "YYY" have been added, but are currently blank.
  • The option "AAA" has been added to the choices, but is not currently operational.

...or is embarrassingly basic:

  • You can now open and save files.
  • These entries have been added to the Edit menu: Cut, Copy, Paste...

I'm looking for a good way to approach these. Should there be a heading just for "Core Functionality"? Or "In Progress"? Should "Known Issues" include things like "This button doesn't do anything yet"?

I've heard that some shops really do write release notes about every incremental change, but I have not found any examples.

  • Don't show half-baked features to the end user, which eliminates the need for documenting them in the realease notes. And things which look "embarrassingly basic:" to you might be really important for an end user: a feature "open and save files" can make the difference between a demo product and a fully usuable application.
    – Doc Brown
    Sep 2, 2021 at 7:32

1 Answer 1


One technique of Continuous Integration is that work in progress gets merged into the main branch, so that all developers see the latest version when they are working on the project. This reduces suprises and nasty merge conflicts. When practicing this, it is normal for unfinished features to exist in the code, but normally they are not visible to users. They are usually "turned off", with techniques such as "feature flags," which allows the code to exist but lie dormant, or become active in certain environments, such as development environments, test environments, or for small pilots, A/B testing, etc.

If choosing to ship with unfinished features visible for some reason, I would say it is worth mentioning in the release notes. Perhaps make another section just for these. But I wouldn't say there is a usual way to do it, because the usual way would be to hide the unfinished stuff.

  • We ship "supposedly finished but not QA'd" and "in development" features all the time. They are documented "AS-IF" they were finished, released, and QA'd, but in a separate section of the release notes titled "not yet released". Therefore, if the customer stumbles across that feature, they are not surprised that it exists at all, but they also know not to use it. However, in our case, it is highly unlikely that an end user will actually see them, the "customer" of our product and thus also the release notes is mostly our own configuration engineers. Sep 2, 2021 at 10:03
  • Basically, R&D writes release notes for everything, product management splits those release notes into "officially released" and "not (yet) officially released". Based on whether they are finished, have been tested, and sometimes we simply have not figured out how to license, price, and market the feature yet. Sep 2, 2021 at 10:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.