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.

iteration

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.

team-iteration

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).

default-process

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.

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 (http://i.imgur.com/YHE7Sst.jpg… ? 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: https://tp3.uservoice.com/foru

  • 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: https://www.targetprocess.com/

  • 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.

  • http://www.targetprocess.com/guide/ 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: https://servicedesk.targetprocess.com/request/145549

  • 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.

Try for free

Account url: *.tpondemand.com
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy