Content
View differences
Updated by Jens Ulferts 4 months ago
**As** a user following agile methodologies
**I want to** have sprint objects connected to work packages
**so that** I can group work packages by sprints in which they are worked on
**Acceptance criteria**
* Sprints exist in OpenProject. They have
* a selection for the projects the sprint is shared with (similar to versions). The options are: versions)
* none - not shared at all. The sprint is available in \[Open\] Should the project it is defined in.
* subprojects - The sprint is available in the project it is defined in and its subprojects.
* all projects/systemwide - The sprint is available in all projects of the instance. same options be used as for versions?
* a name (plain text) - same across all shared with projects
* a start and a finish date (dates) - same across all shared with projects
* a goal (plain text) - different between shared with projects
* a status - same across all shared with projects
* The list of status is a fixed set.
* \[open\] list of status that exist
* a capacity - different between shared with projects
* story points or days
* \[open\] will we support both from the start?
* The user can connect a work package to a sprint. A sprint can be associated to multiple work packages.
* The sprint property can be administrated in the form configuration and be displayed in the project list and in the work package view. configuration.
* Sprints can be selected using an autocompleter. All sprints shared with the project are selectable (grouped by project) regardless of whether the user can see the project the sprint is defined in.
* The property can be used to filter, sort and group in the work package list.
* The property is journaled.
* \[open\] How is the order the work package is in within the sprint kept. Is this "position" something that is visible to the user?
* \[Assumption\] Work packages can only be associated to sprints that are shared with the project. Even if the user is allowed to see different sprints, will sprints not shared with the project the work package is in not be eligible for association.
* Sprints are exposed via an API.
* Sprints are part of the work package API (resource, form, schema including available values)
* \[open\] is there a list of sprints (filterable by project)?
* This would be necessary for the mobile app
* \[open\] Can sprints be created, updated and deleted via the API?
* Versions are no longer used by the existing Backlogs module. Sprints are used instead.
* Only the left hand part of the backlogs main view will use sprints. Backlogs (currently displayed to the right) will continue to use versions (subject to change later).
* Existing versions used as sprints are migrated.
* The goal is to have an uninterrupted user experience when switching from the pre-sprint state to the post-sprint state.
* A version is migrated to a sprint if
* the version is configured to be displayed "left" (for "Column in backlog") in a project
* Backlogs is active in that project
* the version has at least one work package associated to it in that project
* Name, start & finish date, status and sharing is migrated
* \[open\] Mapping of status
* \[open\] Mapping of sharing
* The existing connection from a work package to a version is kept
* The reason for this is that we cannot differentiate programatically whether a version was only used as a sprint or if it also served the role of a version.
* Work packages associated to a migrated version are associated to the created sprint.
* The button reading "+ Version" is changed to "+ Sprint" and opens the sprint creation form.
* The "Properties" menu entry in the sprint menu will lead to the sprint edit form.
* The "Wiki" menu entry from the sprint menu is removed
* The "Stories/Tasks" menu will lead to the work package list filtered by the sprint.
* The version form no longer has the "Column in backlogs" select field. Instead a "Used as backlog" checkbox is displayed.
* The limitation on the work package type (which type qualifies as a user story, which one is a task) remains unchanged.
* The task board will be using the sprint
* The burndown chart will be using the sprint
**Technical notes**
* <br>
**Permissions and visibility considerations**
* _To whom is this feature visible?_
* _When is it not visible?_
**Translation considerations**
* _Key terms and phrases in the key languages_ languages_
**Out of scope**
* Having a sprint board (for now)
**I want to** have sprint objects connected to work packages
**so that** I can group work packages by sprints in which they are worked on
**Acceptance criteria**
* Sprints exist in OpenProject. They have
* a selection for the projects the sprint is shared with (similar to versions). The options are:
* none - not shared at all. The sprint is available in
* subprojects - The sprint is available in the project it is defined in and its subprojects.
* all projects/systemwide - The sprint is available in all projects of the instance.
* a name (plain text) - same across all shared with projects
* a start and a finish date (dates) - same across all shared with projects
* a goal (plain text) - different between shared with projects
* a status - same across all shared with projects
* The list of status is a fixed set.
* \[open\] list of status that exist
* a capacity - different between shared with projects
* story points or days
* \[open\] will we support both from the start?
* The user can connect a work package to a sprint. A sprint can be associated to multiple work packages.
* The sprint property can be administrated in the form configuration and be displayed in the project list and in the work package view.
* Sprints can be selected using an autocompleter. All sprints shared with the project are selectable (grouped by project) regardless of whether the user can see the project the sprint is defined in.
* The property can be used to filter, sort and group in the work package list.
* The property is journaled.
* \[open\] How is the order the work package is in within the sprint kept. Is this "position" something that is visible to the user?
* \[Assumption\] Work packages can only be associated to sprints that are shared with the project. Even if the user is allowed to see different sprints, will sprints not shared with the project the work package is in not be eligible for association.
* Sprints are exposed via an API.
* Sprints are part of the work package API (resource, form, schema including available values)
* \[open\] is there a list of sprints (filterable by project)?
* This would be necessary for the mobile app
* \[open\] Can sprints be created, updated and deleted via the API?
* Versions are no longer used by the existing Backlogs module. Sprints are used instead.
* Only the left hand part of the backlogs main view will use sprints. Backlogs (currently displayed to the right) will continue to use versions (subject to change later).
* Existing versions used as sprints are migrated.
* The goal is to have an uninterrupted user experience when switching from the pre-sprint state to the post-sprint state.
* A version is migrated to a sprint if
* the version is configured to be displayed "left" (for "Column in backlog") in a project
* Backlogs is active in that project
* the version has at least one work package associated to it in that project
* Name, start & finish date, status and sharing is migrated
* \[open\] Mapping of status
* \[open\] Mapping of sharing
* The existing connection from a work package to a version is kept
* The reason for this is that we cannot differentiate programatically whether a version was only used as a sprint or if it also served the role of a version.
* Work packages associated to a migrated version are associated to the created sprint.
* The button reading "+ Version" is changed to "+ Sprint" and opens the sprint creation form.
* The "Properties" menu entry in the sprint menu will lead to the sprint edit form.
* The "Wiki" menu entry from the sprint menu is removed
* The "Stories/Tasks" menu will lead to the work package list filtered by the sprint.
* The version form no longer has the "Column in backlogs" select field. Instead a "Used as backlog" checkbox is displayed.
* The limitation on the work package type (which type qualifies as a user story, which one is a task) remains unchanged.
* The task board will be using the sprint
* The burndown chart will be using the sprint
**Technical notes**
* <br>
**Permissions and visibility considerations**
* _To whom is this feature visible?_
* _When is it not visible?_
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* Having a sprint board (for now)