This week I have been shepherding our latest release into the production environment and I got stuck with the task of doing the release notes as well. The trouble with release notes is that they are boring and unloved.
Release notes tend to be just lists of changes which hardly makes for inspiring reading. If you’re bored when writing them then why would you expect anyone reading them to continue to plough through the dross. You won’t necessarily have a large audience and you don’t need to write the next best seller but you can make them more engaging and easier to digest for those that do read them.
Wikipedia defines release notes as “…documents that are shared with end users, customers and clients of an organization…[that] detail the corrections, changes or enhancements made to the service or product the company provides”. This means that you have an audience of internal and external users that want to know what has changed in your product since the last release and so you should help them do this as quickly and pain free as possible.
In order to digest release notes it makes sense to order them into sections which means you have to do the work of sifting through the changes to categorise them for your readers. I finally settled on a template with help from this post.
This should contain the name of the product, the version and the date of release.
This should be a headline description of what’s in the release. A few sentences should do.
List any new features and functionality here. This might be at the user story level and could include links to the work item.
Outline what changes and enhancements you have made to existing features. Again, include a link to the work item if you can.
Put your bug fixes so that your users know that you are removing errors from the system.
These are under the hood changes that are not necessarily important to the users of the system but should be tracked. Include items here such as infrastructure changes or changes to deployment.
I’ve also had some success with a slightly more humorous version, but you might have to think carefully about your audience.
Ultimately, making your release notes clear and unambiguous shows that you are committed to engaging with your end users and can only help with the success of your product. Do your readers a favour and love your release notes.
The Manifesto for Agile Software Development states “Working software over comprehensive documentation” and for a long time many teams and individuals have taken this to mean that we don’t need to document our software.
Writing documentation can be hard. Not everyone is a fantastic wordsmith, especially in the development community where, mostly, we just want to build stuff. However, the same manifesto also states “Individuals and interactions over processes and tools”. What better way to enable individuals than to have decent documentation. Documentation that points you in the right direction, that explains things in ways that the code never can. Documentation that records design decisions so that those same interactions flow well.
Simon Brown, in his book “Visualising Software Architecture“, and Patrick Kua in his talk “Travel Guide to Software Systems” both advocate a “travel guide” style set of documentation. They argue that context setting is a necessary component of software development in much the same way that you would use a travel guide and map as a way to orient yourself in a city or country that you are unfamiliar with.
The travel guide concept is useful because it suggests a lightweight approach; something to get you started on your journey. An entry point into the tangled mess of an unknown software application. It can outline areas to watch out for. It can serve as a reminder for those who have travelled there before, including ourselves since we can often forget where we’ve been in this modern world of multi-tasking on projects.
What are the best things to document? Simon Brown suggests at a minimum you should include the following:
This should outline what the software project is about. Who the main users and stakeholders are.
Include some kind of context diagram.
This expands on the context to outline the use cases of the system. What are its main features. What is the business workflow the system replicates. Some facts about the domain and glossary of terms.
These are the non-functional requirements of the system such as scalability, performance and security.
This might include standards or protocols the system follows or constraints of the technology being used.
This can be about the culture around the development. Some examples here include coding standards or styles, logging, always use dependency injection, use Swagger rather than RAML, prefer thin client,
position of brackets, naming of tests.
Here you might find architecture diagrams (component/sequence/flow diagrams).
Discussion of the key architecture patterns, perhaps layering strategy. What are the deployable units.
Where the software is deployed. Describe the physical hardware, database servers, message buses. Who maintains it. Backup and Disaster Recovery strategy.
How the software is deployed to the infrastructure. Automated/Manual processes. Configuration settings. Deployment rollback strategy. Data replication.
How the system is run and monitored. How problems are diagnosed. Housekeeping tasks. Data archiving.
Setup of tools and environment needed to develop the system. Build and test instructions. Username and password location.
Start by imagining that you were on-boarding new people to the project. What do you think they need to know? Create answers to those questions and build up the documentation as you go. Make sure everyone is involved and above all remember to keep it light, exposing the essential details.
Don’t forget the documentation.