When teams form and discuss their “Definition of Done” it is easy to omit User Documentation. Especially in the early stages and when the team is small.
We recommend including documentation in regular releases (e.g. every 2 weeks) even in lean cases. And we are happy to do it.
First of all, it is not unusual for science and engineering algorithms to have many parameters. So it should go without saying there that needs to be some user guidance in the first release.
Less realized are the benefits that documentation offers along the path of development.
Demos can be required frequently for young software. Naturally we demo at the end of each iteration. But, investors, pilot clients, and potential employees can also require demos.
Documentation provides a useful script for all these demos, and it can be refined each time.
It seems even mature companies can have a poor on-boarding process. A new software project is even less likely to have any extra mentor-time. While there is no substitute for one-on-one training, having up-to-date documentation for the product makes for efficient learning. And, as a reminder to developers, the next folks who need to learn the software may not write code for a living.
Mature QA organizations can have thousands of pages of testing scripts validating many modes of operation across all features. But when a tester is first hired he or she is likely starting from zero. Again, documentation offers a valuable starting point without costly coordination.
As a matter of fact, good documentation can serve as the source material for other important business functions: training, marketing, valuation, risk-mitigation, strategy, …
So, document early and keep it up to date.
September 15 , 2014 
