Iterations (Sprints) and Team Iterations

There are two types of Iterations: Iterations (Project Iterations, Sprints, Project Sprints) and Team Iterations (Team Sprints). Both are planning entities. They represent a short period of time during which planned work should be completed.

Iterations and Team Iterations serve the same purpose: organizing work for planning, tracking, and reporting. The main difference between them is the scope of work each type may contain.

An Iteration is a part of a Project and Release by nature. It can contain work only from one Project and a single project Release.


Team Iterations are similar to Iterations, but are not related to a Project. A Team Iteration is related to a Team and can contain work from many different Projects and Releases.


Iteration (Sprint)Team Iteration (Team Sprint)
Can contain stories, tasks and bugs assigned to1 Projectmany Projects
Can contain stories, tasks and bugs assigned tomany Teams1 Team
Can contain stories, tasks and bugs assigned to1 Release, alwaysmany Releases
Belongs to parent Release1 Release assigned to 1 Project only, alwaysnever
Belongs to parent Project1 Project, alwaysnever
Belongs to parent Teamnever1 Team, always

Effort Units

The total assigned effort and velocity of Iterations and Team Iterations is measured using single planning unit (points or ideal hours) across all assigned entities (work items).

For Iterations, the effort unit is defined in the settings of the process of the Project the Iteration belongs to.

For Team Iterations, the effort unit is overridden by the settings of the process marked as "Default Process" in your global settings (Settings → Processes).


Assign Features, Epics and Releases

Both Iterations and Team Iterations cannot contain Features and Epics. These high-level requirement entities can be assigned to Releases only. However, Iterations and Team Iterations can contain Stories, Tasks, and Bugs that are part of Features and Epics.

Iterations cannot be assigned to cross-project Releases.

Filters for Sprints (Iterations) and Team Iterations

You can select, hide or highlight data in Views and Visual Reports by Sprints (Iterations) or Team Iterations and related properties using Advanced Filters for Sprints (Iterations) and Team Iterations.

Team Iterations and Releases

In a case when you have multiple related projects running together you can to coordinate them with cross-project Releases. When you have a team working on many projects in the same time, you can plan and organize work of the team with cross-project Team Iterations. Team Iterations cannot be assigned to Releases. However it is still possible to assign a work item such as User Story, Task, or Bug both to a team iteration and to a cross-project Release.

The figure below illustrates the setup. Team A works on two projects, Project X and Project Y. The team is assigned to both projects. Work of the team is organized with Team Iterations. Team Iterations #1, #2, #3 are assigned to the Team A. Work on the projects is coordinated using cross-project Releases. Releases #1, #2 are assigned both to Project X and Project Y. Team Iterations are not assigned to Releases. Every work item is assigned to a single Project, Release, Team, Team Iteration.


For additional transparency, we recommend to add outbound relations from Releases to Team Iterations.

Future plans

In our public backlog, we have an idea to unify Iterations and Team Iterations. We will keep gathering feedback on it.

  • Ironbelly Studios

    How does one change the owner of a Project Iteration (… ? They seem to default to me as I was the creator but we need to assign them to other people.

    We have multiple iterations and potentially multiple releases and some of those iterations will be run by different people so I would like to allow them to filter by Iterations that they own however all iterations seem to be owned by me and there doesn’t seem to be any way to change that.

    One idea is to simply allow us to edit the owner like we do user stories, another idea is to add a owner field to releases and then iterations will inherit the owner of that.

    The best solution would be both of the above obviously but we’ll take what we can get 🙂

  • Alex

    Actually, ‘Owner’ field for Iterations and Releases is hidden one, reserved for system purpose. It is always defaults to a creator and indeed, our UI does not have capability to change it. Moreover, in detailed view of an entity its owner is not displayed.

    It seems that when we created customized cards, we made it possible to add ‘Owner’ unit to these cards. With current implementation, this field is almost useless.

    I have to inform you that, if you want, technically you can edit an owner for an iteration – within direct call to Targetprocess REST API. Do POST to the following path: https://youraccountname.tponde

    And send the following header:
    Content-Type: application/json

    And payload:
    “Owner”: {
    “Id”: 123

    Here 1234 is ID of an iteration which you want to modify, and 123 is ID of a user you would like to set as Owner. If everything goes well, you’ll receive:
    Status: 200: OK

    We do not recommend to use Owner field this way, for sure. Please submit your ideas to our suggestions portal:

  • Rock Jing

    If we switch project iteration to team interation, so how did we plan the product release plan?

  • Natalia

    Hi Rock,
    If you switch from Iterations to Team Iterations, you can still plan Releases. The difference is, Team Iterations do not have direct relation with Releases. That means one Team Iteration in theory can have work from different Releases.
    Additionally, if you do not use Project Iterations, you can benefit from using Cross-Project Releases:

  • Wojciech Liwanowski

    What is the purpose of this setting – “For Team Iterations, the effort unit is overridden by the settings of the process marked as “Default Process” in your global settings (Settings → Processes).” ?
    Some of our teams estimate with points, some with i-hours, they work in different processes and in different projects, but in the team sprints (and only there afaik) units are marked as points, although the sum is for hours.

  • Alex

    Actually it is made not intentionally. It was just quickest way how total effort could be implemented for Team Iterations. For sure it could be handled better: use effort unit from the process the entities assigned to the team iteration are following. We gather feedback on this non-implemented capability and I’ve added your vote and submitted your comment to it:

  • Wojciech Liwanowski

    Thank you for an answer. Although for me it’s more a bug than a feature 🙂 Sure, vote for proper resolution of this problem, but I’m sure there is a quicker and simplier way to resolve this – whether default process or not, refer to the process used for this team (instead of process).
    Severity – very low, difficulty – probably very low. And there’s a problem only on Team Sprint view/hierarchy, nowhere else. Calculating chances for implementing this feature by the voting => close to none 🙂

Still have a question?

We're here to help! Just contact our friendly support team

Find out more about our APIs, Plugins, Mashups and custom extensions. Join our community of passionate users and even discuss directly with our developers.