Content
View differences
Updated by Jens Ulferts 4 days ago
**As** an agile user
**I want to** have a sprint overview page with an overview of the sprint
**so that** I can easily understand what happened in the sprint
**Acceptance criteria**
* There is a sprint report page
* The header shows:
* the breadcrumb: \[Project name\] / Backlogs / All sprints / Sprint "\[Sprint name\]" report
* \[open\] Why not use \[Project name\] / Backlogs / Sprint "\[Sprint name\]" / Report?
* The title: 'Sprint report "\[Sprint name\]"'
* The status of the sprint
* The dates of the sprint
* A single, static widget is displayed on the page (subject to change later)
* overview over wp # within the sprint
* number of work packages initially planned for the sprint
* number of work packages completed
* number of work packages unfinished
* number of work packages added additionally to the sprint during the sprint
* \[note\] The specification on this \[open\] use a different widget for the first one? Ideally it is still changing. It might well a simple one as this work package should be that e.g. <mention class="mention" data-id="74098" data-type="work_package" data-text="###AGILE-198" data-display-id="AGILE-198">###AGILE-198</mention>will have used to be taken into consideration, especially if "work" or " none" is selected as lay the unit. foundations of the report page. At the same time, it should add value.
* The page can be accessed:
* via all sprints index page
* \[open\] How will this be triggered? For completed sprints, it could replace the main link currently pointing to the work package list. For the planned one, replacing the main link is probably not desirable. Adding a menu per row is probably preferable.
* via ... menu on sprints within the "backlog and sprints" page
* The "Burndown chart" menu item will be replaced by the link to the report page (if the feature flag is active)
* from the sprint board
* \[open\] we currently cannot control the headers. This will only be possible with the reworked boards view.
* The feature is hidden behind a feature flag. This is done so that additional widgets can be added one by one before it is released to the public.
**Technical notes**
* The page will be static. There is no possibility whatsoever for the user to configure it. But the page should look like a dashboard so that a configurable dashboard can later replace it.
**Permissions and visibility considerations**
* Users allowed to view the sprint are allowed to see the page and its contents.
**Out of scope**
* Manipulating the report page (subject to change)
* Show additional widgets (subject to change)
<br>
**I want to** have a sprint overview page with an overview of the sprint
**so that** I can easily understand what happened in the sprint
**Acceptance criteria**
* There is a sprint report page
* The header shows:
* the breadcrumb: \[Project name\] / Backlogs / All sprints / Sprint "\[Sprint name\]" report
* \[open\] Why not use \[Project name\] / Backlogs / Sprint "\[Sprint name\]" / Report?
* The title: 'Sprint report "\[Sprint name\]"'
* The status of the sprint
* The dates of the sprint
* A single, static widget is displayed on the page (subject to change later)
* overview over wp # within the sprint
* number of work packages initially planned for the sprint
* number of work packages completed
* number of work packages unfinished
* number of work packages added additionally to the sprint during the sprint
* \[note\] The specification on this
* The page can be accessed:
* via all sprints index page
* \[open\] How will this be triggered? For completed sprints, it could replace the main link currently pointing to the work package list. For the planned one, replacing the main link is probably not desirable. Adding a menu per row is probably preferable.
* via ... menu on sprints within the "backlog and sprints" page
* from the sprint board
* \[open\] we currently cannot control the headers. This will only be possible with the reworked boards view.
* The feature is hidden behind a feature flag. This is done so that additional widgets can be added one by one before it is released to the public.
**Technical notes**
* The page will be static. There is no possibility whatsoever for the user to configure it. But the page should look like a dashboard so that a configurable dashboard can later replace it.
**Permissions and visibility considerations**
* Users allowed to view the sprint are allowed to see the page and its contents.
**Out of scope**
* Manipulating the report page (subject to change)
* Show additional widgets (subject to change)
<br>