Sometimes, user documentation is not a nice to have but a legal requirement or a requirement to meet a standard like the FDA. But more important, quality user documentation improves the usability of the product and enhances the credibility of the company.

During Scrum adoption, people tend to get away from tasks and activities that they don’t like in traditional projects like documentation or writing proper code comments. In this article, a ScrumMaster shares his experience with a “no documentation” approach. He learned the hard way that minimal documentation is better than no documentation in Scrum projects. The team can decide on a case-by-case basis what level of documentation for which components and code logics is needed.

Does the term “documentation” have any place in an agile environment? The goal on agile projects is to keep documentation as simple as possible, relying on roadmaps, overviews and concepts rather than enterprise-focused details. But what happens when using an agile approach on more complex projects? For example, what if the team that writes the software is different from the team that must maintain it? Or what if auditors come calling? In these instances, basic agile documentation based on user stories alone may come up short. This article provides insights …

Upfront Modeling is fine, documents describing the intended architecture are fine, and so forth. But the architecture, and our learning about it, can improve. Speculative software architecture should be made concrete and not of concrete.