# Feature AGILE-389 - Provide epic progress chart within the sprint report

Project: Stream agile
Status: merged
URL: https://community.openproject.org/work_packages/AGILE-389

## Planning

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | Medium |
| Target versions | 18.0.0 |
| Sprint | Sprint 13 |
| Backlog bucket |  |
| Votes |  |
| List | Agile Reporting |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

_No work packages_

## Bugs and other work packages

_No work packages_

## Technical Details

| Attribute | Value |
| --- | --- |
| Module | Modules and project features / Backlogs |
| Feature Flag | Sprint reports |
| Requires doc change | Yes |
| Enterprise plan | Enterprise / Professional (PRO) |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups | https://www.figma.com/design/owpxg3fdqZONIGL6SBSG8M/Agile--Sprint-reports?node-id=2053-17407&t=HYsVDC5p8jaXmu53-0 |
| Accessibility | No |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers | Tobias Dillmann |
| Designer | Julia Racsko |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| PD (min) |  |
| PD (max) |  |
| Work |  |
| Labor costs |  |

## Description

**As** a agile user  
**I want to** like to see in a visual way a progress of relevant epics within the reported on sprint  
**so that** I can understand how the team is progressing on the epic execution

**Acceptance criteria**

*   The sprint reports page has a widget called "Epic progress"
    
    *   Other than what the mockup depicts, the widget spans the complete width
        
        *   The progress bars shouldn't span the whole width on larger screens. The CSS rules on progress bars should already provide a limit to them. 
            
*   The widget shows those epics that work packages assigned to the sprint are ancestors of
    
    *   Key information of the widget is displayed: type name, id, status and title. A link on the title takes the user to the epic.
        
    *   A progress bar displays the ratio of completed work packages vs all work packages. Both of those sets of work packages contain only work packages that are descendants of the epic. 
        
        *   The visual indication is bolstered by stating the absolute number as well as the percentage.
            
        *   The widget is time conscious. Values are taken at the time the sprint completed if the sprint is already closed. That includes the status of the widgets but also the ancestor relationships. E.g. if a work package is moved to a different epic after the sprint is completed, it should still be counted.
            
            *   \[restriction\] If a work package is removed, the information about it is removed completely. Old reports might change when a work package is removed.
                
        *   The depth of the hierarchy does not matter excluding the epic. E.g in a hierarchy where an epic has two story children each having 3 tasks, the number of work packages would be 6 (tasks) + 2 (stories) = 8.
            
        *   Work packages of types configured to be ignored by backlogs ("Excluded work package types") still counted as part of the sum.
            
        *   Descendant work packages might stretch multiple projects. Regardless of the project the descendants are in, they are part of the sum. Invisible work packages (permissions) are ignored. Epics in other projects than the sprint are displayed just the same.
            
*   The epic type is searched for by its name "Epic". 
    
    *   If the seeded type is renamed or removed and the epic type cannot be found, the widget is not displayed.
        
    *   Variants of the found type should be displayed with the same "Epic" name just like the non variant epic.
        

**Technical notes**

*   The current idea is to reuse the work package cards introduced for resource management
    

**Permissions and visibility considerations**

*   Only epics visible to the user should be displayed
    
*   Only work packages visible to the user should be displayed
    

**Translation considerations**

*   _Key terms and phrases in the key languages_
    

**Out of scope**

*   There is no limit on the number of epics displayed. We'll recheck later if that leads to problems.
    

_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._