What this screen is for
Iterations divide a project by time. Each one carries a name and an optional start and end date, and they nest, so a release can hold the iterations inside it. Every row shows how many work items are scheduled into it. An iteration can also be linked to a sprint, which ties the schedule to the team's working cycle.
You pick a project first, then add root iterations and children beneath them. An iteration with children, or with work items assigned to it, cannot be deleted.
When to use it
Define iterations when you want to plan work into dated windows rather than only order it. They then appear as a column and a filter on the work-items grid and as a grouping on the backlog.
What you see on this screen
Iterations are shown as a tree rather than a table. Each row carries:
- Iteration name — indented to show its depth.
- A count — how many work items are scheduled into it.
- Dates — the start and end as a range, or a dash where none are set.
- Three actions — Add child, Edit and Delete.
Filters and actions
Choose a project first; until you do, the page says to select one. Root Iteration adds a top-level iteration and Add child adds one inside it, with the parent path shown above the form.
The form takes a Name, a Start and End date, and an optional Sprint, which is how an iteration is tied to the team's working cycle. Deleting refuses where an iteration has children or still holds work items.
Related
- Areas — dividing the same project by subject instead
- Sprints — the working cycles an iteration can be linked to