agile framework scrum document models

Documentation may be negotiated on the Product Backlog or otherwise committed to in the Definition of Done, then planned and actioned in a timeboxed manner on the Sprint Backlog.

I agree with Ian.

The document model is embedded in three artefacts:

Product Backlog

Sprint Backlog

Iteration (/aggregated iterations)

The nuance in Scrum is to get the organisational document model/taxonemy integrated coherently into the definition of done. On successful product teams I have worked on that meant getting the documents to a place where document impact maps are as easy to understand as feature impact maps are. If you know what features/functions you're touching in your product, you then know what documents have a mandatory/highly recommended/optional update. 

The Product Backlog is the primary source of documentation as it is a living body of information about what work needs to be done to the Product. 

The key is that any documentation being created and maintained needs to have value to the team and the organization.  It needs to provide insights into the work being done and not be created for the sake of checking a box on a checklist.  Also it needs to actually reflect the work as it happens.  The Product Backlog is the only documentation that drives the work that is being done. No other documentation should impact the work being done or the way that work is done.  

There could be some documentation that is required by the organization.  For example, some companies require "Run Manuals" which the IT Operations teams will use to keep the application running in a production environment.  As such, the Scrum Team will need to provide and update that documentation.