One of the SevenPillarsOfCred

'''Short Wiki version'''

Write down (in addition to source code) only what is needed for verifiable SuccessStatement's with customers - to gain the budget and other resources required - and then to deliver the next increment (including tested code plus training) that will be considered a success by customers, in line with one or more SuccessStatement.  

How much documentation is in fact needed is of course context dependent, with the most important elements being: the ''trust'' between the customers and the design team (programming team) and the current ''know-how'' of everyone involved (including knowledge of the business domain and thus tacit knowledge of customer desires by designers), in line with KnowHowToGrow.

In a well conceived and executed evolutionary project, trust and know-how grow from the earliest stages, meaning that documentation of future deliveries can become more and more "informal". (In fact because the few words used convey a more exact understanding of what is required than earlier on, it is arguably wrong to use that term.)  This is ''steady state'' development.  Then suddenly on a Monday an idea of great business value occurs to the customers/designers, it can be ScribbledOnOnePage in a few minutes and be working by the Friday.

----

All of this implies the same emphasis on verbal communication and elucidation of goals that one picks up in XP UserStories - points well summarised by AlistairCockburn in RequirementsAndDesign.

Note that there's nothing about IndexCard''''''s here, nor how to use Wiki.  Their combination and interaction is very important in the practical outworking of DocumentToDeliver these days, including KnowingWhenToStop.  Thanks again Ward.

Note also the issues with annual budgeting.  Not always quite so easy.  See IsEarlierCancellationFailure and XpAndAnnualBudgets for some (hopefully) unfinished discussion of these issues.