Date: Thu, 28 Mar 2024 20:21:46 +0100 (CET) Message-ID: <155305469.17479.1711653706088@09e9d69a2016> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_17478_454947750.1711653706088" ------=_Part_17478_454947750.1711653706088 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Describes an information = need and use this description as a basis to create and maintain a document.=
Agile documentation is about to provide information that is really neede= d. Agile documentation needs to be valuable, essential, and available just-= in-time.
Therefore a stakeholder is required to define what is required, to what = extend, and at which time.
A charter document starts a documentation session by defining what is re= quired.
The document type charter provides the following properties:
Please note that only information about specific properties is provided = here. Common document property used by all document types are documented by= Document Propert= ies.
The Charter Type = allows to organize charters by type.
Define the timebox within to run the session.
Define the documented information type of the new document as either record
.
Specify a list of stak= eholders that are interested in the information and therefore sponsor i= t.
List the names of stak= eholders who may provide additional information on the area being exami= ned.
Add a reference to the root of the documentation created based on this c= harter.
This allows interested stakeholders to navigate to the created documents= quickly.
Document the purpose of this charter. This may contain the whole charter= information in a couple of sentences.
Write a short summary about the result intended for team members and oth= er stakeholders
State where the exploration is taking place.
List the tools to employ to run the exploration.
List the information the sponsors are interested in. May state a problem= to be solved.
Teams may want to break a larger charter into smaller charters to have s= everal, more focussed sessions. In this case add the additional charters as= child pages to this document. Keep in mind that the child relationship ind= icated that if - for some reason - the parent charter is removed, all child= ren should be removed, too. If this is not the case, better add the charter= s to the homepage.
These are internal notes that are usually not exported and only visible = to team members with write access.
But this is not a safe place to store sensible informat= ion. It is just a convenience for the reader to not be bothered with notes = stored here for the authors for later use. The security level is about supp= ressing the representation by a CSS style. Therefore consider this as a con= venience for the reader, not as a security tool.
The text of notes sections is also indexed.
For a document the references section contains pointers to resources tha= t prove the statements of the document.
Often these proofs are not easily distinguishable from further informati= on. In this case you may want to skip the reference section in favour for t= he resource list.
For further information please refer to References and Resources.
The resources section provides references to further information to the = topic of the document.
This may be information on the internet provided by the resource or info= rmation in the team's information systems. Anything the reader of the resou= rce might want to know, may be listed here.
For further information please refer to References and Resources.