# Epic AGILE-130 - Allow multiple active sprints within a single project

Project: Stream agile
Status: closed
URL: https://community.openproject.org/work_packages/AGILE-130

## Detailed specification

### Motivation and background information

Currently, OpenProject supports only a single active sprint per project at any given time. This constraint limits teams that operate multiple workstreams, sub-teams, or parallel delivery tracks within the same project.

Teams that manage multiple workstreams or release tracks within a single project face the following pain points under the current model:

*   Only one sprint can be marked as &quot;active&quot; at a time, forcing teams to merge distinct workstreams into a single sprint or create separate projects as workarounds.
    
*   Creating separate projects for parallel tracks fragments backlog visibility, makes cross-track reporting difficult, and increases administrative overhead.
    
*   Scaled Agile frameworks (SAFe) and multi-team setups require simultaneous sprint execution, which is not supported today.
    
*   Sprint boards, burndown charts, and velocity reports cannot reflect the reality of teams running parallel iterations.

### Acceptance criteria

Main goals:

*   Allow project administrators to define a project as a single-sprint or multi-sprint project.
    
*   Allow users to activate multiple sprints simultaneously within a single project. There is a start button on each available sprint bucket.
    
*   Ensure each work package can be assigned to exactly one sprint, preserving clarity of ownership.
    
*   Update sprint boards to correctly scope data to individual sprints when multiple are active. Each active sprint should have a separate sprint board.
    
*   The sprint board gains a sprint filter to display one or more active sprints simultaneously (multi-select list shows single sprints and gives a possibility to quickly select all sprints as well)
    
*   Burndown and burnup charts are generated per sprint.

### Out of scope

This epic does not change the sprint planning workflow beyond enabling parallel active sprints.

| Attribute | Value |
| --- | --- |
| Mockups | https://www.figma.com/design/yRewu4Y5nuWCa8aMM3DFw3/Agile--Sprints-and-Backlogs?node-id=384-20636 |

## Planning

| Attribute | Value |
| --- | --- |
| Roadmap | 2026 Q3 |
| Date | 2026-07-24 |
| Votes | 2 |
| List | RM Jira exit |
| Target versions |  |
| Sprint |  |
| Backlog bucket |  |
| Relevance |  |

## Subitems

| ID | Type | Subject | Status | Assignee | Target versions | Project | Priority | Spent time |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| AGILE-326 | Feature | Multiple active sprints without sharing | closed |  | 17.7.0 | Stream agile | Medium |  |

## Bugs and other work packages

_No work packages_

## Details

| Attribute | Value |
| --- | --- |
| Module |  |
| Enterprise plan | Enterprise / Basic (BAS) |
| Labels |  |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Designer | Parimal Satyal |
| Developers | OP Dev Polaris Team |
| Requested by |  |
| Interest by | BJ (37264), Tiziano (37949), Black (37919) |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| Work | 20d 0h · Σ 20d 0h |

## Description

**As a** user,   
**I want to** start multiple sprints simultaneously within a single project,   
**so that** parallel workstreams and sub-teams can each operate in their own dedicated sprint without requiring separate projects.

### Acceptance criteria

  - **In general**,
    
      - The notion of a single "Active sprint" dynamic link per project no longer exists; there can however be an "Active sprints" (plural) link that lists all active sprints

  - **In project settings,**
    
      - Specifications here: <mention class="mention" data-id="77079" data-type="work_package" data-text="###AGILE-326" data-display-id="AGILE-326">\#\#\#AGILE-326</mention>

  - **In the "Backlog and sprints" page,**
    
      - ~~Rename it to "Backlogs and sprints" (both plural)~~ \[RS: there is only one backlog. The name should stay as it is.\]
    
      - Show the "Start sprint" button on all sprints that are in planning (if multiple sprints are enabled for a project)
        
          - If there is a max limit set (see open question), then disable the button after that number has been reached.
    
      - In the "Sprints" column, the active sprints are displayed on top (ante-chronological, with the earliest ones on top)
    
      - The 'All sprints' page still shows all sprints, but this page can now show multiple sprints as active
    
      - Clicking on any active sprint takes you to the board for that particular sprint
    
      - 
        
        <br>

  - **In the Boards module,**
    
      - The "Active sprint" link becomes a menu with sub-items and is renamed "Active sprints". Users can click on this to see all active sprints:
        
          - \[open\] Either in the a sub-menu in the sidebar or an index page of active sprints

### Open questions

  - Which of the following models do we imagine for multiple active sprints?
    
      - **Option A:** Sprints exist the way they do now, except within a project, multiple sprints ("Sprint A" and "Sprint C") can be active at the same time
        
          - Individual active sprints can start/finish at any date; they do not all have to start the same time
        
          - RS: I would go for option A. I could imagine that one day some teams would like to have the same start/end dates for sprints, but let's wait for the feedback. For the first iteration I would go for option A, without any syncing on dates.
        
          - RS: I assume that if a project is a receiver it cannot even activate multiple sprints, correct <mention class="mention" data-id="87" data-type="user" data-text="@Jens Ulferts">@Jens Ulferts</mention> ?
    
      - **Option B:** Different instances of a single sprint ("Sprint A") active in the project in parallell (eg. "Sprint A.1", "Sprint A.2")?
        
          - The sub-sprints are not shared?
        
          - All parallel sprints share the same start/finish date, such that parallel sprints always start/finish the same time.
        
          - *... (space for <mention class="mention" data-id="87" data-type="user" data-text="@Jens Ulferts">@Jens Ulferts</mention> to add details, possibly)*

  - Should there be a limit on the number of active sprints per project?
    
      - If yes, should this be a setting for the project admin?
    
      - RS: no

  - Are there any particularities to shared sprints?
    
      - If a sprint is shared, it's active in all projects where it is shared
        
          - RS: yes. It should be possible to share multiple active sprints, too. If you a receiver, you probably cannot even change the sprint setting to multiple sprints, correct <mention class="mention" data-id="87" data-type="user" data-text="@Jens Ulferts">@Jens Ulferts</mention>?
    
      - Sprint goals remain per-project

  - Should there be a concept of "team" somehow, when it comes to multiple active sprints? (In the same that, in the same space, multiple teams can have multiple parallel sprints?)
    
      - *Note: This is somehow related to Option B above.*
    
      - *RS: no*

  - Side-feature: Should we have a separate view to view only sprints (and their contents) without the backlog being present? This might make it easier to view multiple sprints at the same time without being distracted by the backlogs.
    
      - RS: no, no adjustments in the backlog view needed
        
          - alternatively users have the possibility to view all the sprints in the work package module if necessary

  - Should there be a way to see all active sprints (to which a user has access) at a global, all-projects level?
    
      - RS: yes, but this is out of the scope for now. We will address it within <mention class="mention" data-id="71890" data-type="work_package" data-text="##AGILE-63" data-display-id="AGILE-63">\#\#AGILE-63</mention>

  - How do we handle permissions for multiple active sprints? From <mention class="mention" data-id="99090" data-type="user" data-text="@Tobias Dillmann">@Tobias Dillmann</mention>:
    
      - Permissions are  managed on a per-project level.
        
          - RS; that's ok. No changes.
    
      - `view_sprints` or `manage_sprint_items` is set for a project
    
      - if you have multiple teams working on different sprints *in the same project*, they all would need at least `view_sprints`. Allowing them to see the sprints of the other teams of the project. Modifying them, too if granted `manage_sprint_items`.
        
          - RS: I wouldn't see that as an issue. All people (no matter on which team) who need to prepare the sprints should have the modify rights. No team-level permissions needed.

<br>
