Skip to main content

Assigning a Sprint Schedule to a Project

This article explains assigning a sprint schedule to a project.

Overview

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

  • Less coordination is required across teams to define, activate, and close sprints. This is helpful for organizations that have variations in how disciplined teams are in starting and ending sprints on time.
  • Allows different projects to use different sprint lengths.
  • Allows different projects to start and/or end sprints 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 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 Length - default length when new sprints are created. Can be overridden for any individual sprint.
  • Sprint Gap - typically 0. This can be used to note any gap between the end of one sprint and the start of the next. This may be used to account for the weekend if a 5-day sprint is used or for wrap-up and planning time in between successive sprints.

Sharing Sprint Schedules Across Multiple Projects

Sprint schedules can be shared across projects to allows rollup reporting along sprint 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 can 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.

To create or modify a sprint or iteration schedule, both your Admin Privileges role and Project Role must to set to "Project Admin" or higher. See Sprint or Iteration Schedules are not Editable to learn how.

To schedule work into a sprint for a specific project, you must define a schedule in one of the following ways:

Method 1: From the Sprint Scheduling Page

  1. Click (Wrench) icon > Customize from the drop-down menu.
  2. From the Customize Columns window, select the Display and Edit checkboxes for Sprint Schedule column.
  3. Click Save.
  4. In the projects page, locate the project for which the Sprint Schedule is added.
  5. 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 displays, and you can change the Sprint Schedule.

If effort or sprint history has been established, then the magnifying glass is not displayed.

Method 2: From the Project Administration Page

  1. Click Add Child Project and then click Edit from the drop-down menu.

  2. Click on the magnifying glass.

  3. In the Sprint Schedules window, do either of the following:

    • Select a sprint schedule from the list by clicking Select.
    • Click the Add Sprint Schedule, enter the required information in Sprint Schedule window, and then click Save.