One concept you’ll hear tossed about in an Agile discussion is that of “just enough.” You want just enough documentation, just enough development and testing, just enough time for meetings, just enough grooming, and so on. The idea is that doing more than is needed means you have throwaway work when you need to make changes (and changes are going to happen). This just-in-time approach has advantages, but as with everything in life there is a flip-side as well.
When you have just enough documentation, the gaps (which are expected, by the way) are filled in by asking questions of the Product Owner or Business Analyst responsible for elaborating requirements and stories. This usually works pretty well, but if the answers don’t get captured in some form there is a good chance the information could get lost. What you want is some way to easily update information about your requirements, and do so in such a way that the consumers of the information don’t have to crawl through text to parse out the meaning.
This is why I especially like using visual models in an Agile environment. Not only do visual models convey more information quickly, they are also (generally) easier to change than text descriptions. You may need to do a “track changes” sort of approach to show what elements are new, changed, or deleted in a visual model, but that isn’t hard to do. If you use a document repository that keeps versions (and if you don’t, you should), then you check in a “track changes” version for review, then update with a version with “changes accepted” – meaning you can remove the special formatting such as color or bolding.
For example, let’s say you do a Feature Tree for a new product and have a pretty complete set of what would go into a market pleasing release. As time goes on in the project, it becomes evident that some of the features are both difficult to do and not of the highest value to the customer. Although still candidates for releasing in the future, they don’t meet the needs for the first release of the product. If we only want a few L2, L3 features from an L1 branch, we can grey out the features not needed to show they aren’t in the first release. Then we can either remove them entirely, or leave them there as we get to next release planning. Likewise, after the first release, we can have the already released features shown in a different color or font as we look at what the next features are we want to release. You can see how easily a Feature Tree can be used to frame the discussion about what gets released when, as well as adapting to changes.
