Assigning a Sprint/Iteration Schedule to a Project

This feature is available in Catalyst, Enterprise, and Ultimate editions.

Overview

Assigning a Sprint/Iteration schedule to a project has the following advantages:

Less coordination is required across teams to define, activate and close sprints/iterations is required. This is helpful for organizations that have variations in how disciplined teams are in starting and ending sprints/iterations on time.

Allows different projects to use different sprints/iterations lengths.

Allows different projects to start and/or end sprints/iterations on different days, which can be helpful if different projects share a common customer.

Important to Know

The sprint schedule is optional when a project is first created, but it must be created before the team begins Sprint/Iteration Planning.

There can only be one Sprint Schedule assigned per Project, but Child Projects are not required to use the same schedule as the parent.

Sprint/Iteration Length - default length when new sprint/iteration are created. Can be overridden for any individual sprint/iteration.

Sprint/Iteration Gap - typically 0. This can be used to note any gap between the end of one sprint/iteration and the start of the next. This may be used to account for the weekend if a 5 day sprint/iteration is used or for wrap-up and planning time in between successive sprint/iterations.

Sharing Sprint Schedules Across Multiple Projects

Sprint/Iteration schedules can be shared across projects to allows rollup reporting along sprint/iteration lines, for values such as velocity, and can be helpful where an entire group uses the same schedule. If you use the same sprint schedule for a segment of the project tree, you view a report by sprint for a higher level scope and roll up all data from lower-level descendant scopes. When sprint schedules are shared between projects, the same sprints are used for each of the projects. The new scope creation process allows the scope to be designated as having either a shared or independent sprint schedule.

Velocity can be calculated across project levels. For example, one could view the combined velocity of a number of projects that share the same schedule.

Filtering allows a view into all the work in a given sprint time frame. For example, within sprint Tracking, it is possible to view all the work going on in the current sprint together even across multiple concurrent releases or projects.

Less administrative work required to define and manage the schedule.

Projects with multiple teams can define a simpler project tree by taking advantage of the Teams functionality within the system rather than creating separate nodes in the project tree for each team working on a project or release.

Method 1: On the Sprint/Iteration Scheduling Page

Select the "Display" and "Edit" checkbox for "Sprint Schedule" column.

Click the "Save" button.

Locate the project of which the Sprint Schedule is being added/updated for.

Click on the magnifying glass and proceed with selecting a new Sprint Schedule.

If the project currently has a Sprint Schedule, but there has been no work effort or sprint history associated to that project, the magnifying glass will display, and you will be able to change the Sprint Schedule.

If effort or sprint history has been established, then the magnifying glass will not display.