Specify the goal of this iteration to help your team stay focussed.

 Log the start and end date of the duration. If you track your iterations in JIRA and do not need to select on this property in queries, leave it blank.

List the members of the team that take part in the iteration.

Teams may not change often, so you may want to list the team members on another document and transclude them here. If you have only one team in this space, leave it blank and use it only if for some iteration the team size has been reduced (e.g. due to holidays).

Add references to information on external systems here. Probably this is an issue on your JIRA server.

Describe the objectives of the iteration.

This should help the business members to have a brief summary of what business value is produced by the team within this iteration.

List the stories that have been selected by the team for this iteration.

Each story document is a place to share information relevant for implementing the story. You may want to add information to collect for later documentation in your wiki.

If you have information you want to work on later in the iteration, add a working document. This is especially useful if this information is relevant for more than one user story.

Adding such information in written form may help to not forget what may be relevant in the future. The team usually looks through these notes at the end of the iteration to

Each document type has child document support, so does the Iteration Doctype.

Usually this is not used. In the end you have one iteration for one team. But in some cases you want to create an iteration document for some members to work together. A working document is usually preferred.

Take notes on what you want to present to your stakeholders on the review of the iteration. Use the Review doctype to create this document.

Note what worked and what did not with this iteration. Use the Retrospective doctype to create this document.