Content
View differences
Updated by Rosanna Sibora about 1 month ago
**As** a user following scrum methodology
**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, and easily reorganise sprints by moving items between them (and the backlog)
**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 the project it is defined in.
* subprojects - The sprint is available in the project it is defined in and its subprojects (use case: for SAFe ART users will create a project on the portfolio or program level and will be able to pass it on to all subprojects)
* all projects/systemwide - The sprint is available in all projects of the instance.
* a name (plain text) - same across all shared with projects
* we automatically set a name when a user creates a sprint bucket "Sprint 1"
* user can overwrite the name
* for each new bucket we count +1 based on the latest sprint bucket, copying the text part of the sprint name used for the latest sprint, e.g. the one edited by the user
* if user removed the digits in all sprint names in planning, we stop counting
* a start and a finish date (dates) - same across all shared with projects
* a status - same across all shared with projects. The list of status is a fixed set:
* In planning
* Active
* Completed
* The user can connect a work package to a sprint. A sprint can be associated to multiple work packages.
* For now, this is only possible within the Backlog module. <mention class="mention" data-id="71061" data-type="work_package" data-text="##71061">##71061</mention> will add an editable and manageable "sprint" field to work packages.
* The "sprint" property is journaled.
* Work packages have a "position" field to remember the order within the sprint. This field already exists and is left untouched.
* Sprints will later on be exposed via an API (see #71058 and #71061)
* 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).
* The button reading "+ Version" is changed to "+ Sprint" and [opens opens the sprint creation form](https://www.figma.com/proto/yRewu4Y5nuWCa8aMM3DFw3/Agile--Sprints-and-Backlogs?node-id=416-9277&p=f&t=6CQJQUzsbb0dlgvl-0&scaling=min-zoom&content-scaling=fixed&page-id=142%3A13148) (the header of the modal: "Create sprint"). form.
* The "Properties" menu entry in the sprint menu will lead to the sprint edit form.
* Will be renamed to "Edit sprint"
* The "Wiki" menu entry from the sprint menu is removed
* The "Stories/Tasks" menu item will be removed (later on possibly readded by #71061).
* 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**
* Migration considerations:
* 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 is migrated
* \[open\] Mapping of status
* The project the sprint is created in and the sharing it has:
* The project furthest down the hierarchy with the sharing set to "subprojects" - if the sprint is used in multiple projects and they share the same hierarchy
* Just the project where the sprint is used with the sharing set to "none" - if the sprint is only used in a single project.
* The project having the "system-wide" version defined with the status set to systemwide - for a version shared system-wide.
* The existing connection from a work package to a version is kept
* The reason for this is that we cannot differentiate programmatically 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.
* A journal is written by the system user informing about the shift from version to sprint - no notification is sent
* \[open\] Phrasing of the message
* Permissions need to be migrated (see below)
**Permissions and visibility considerations**
* Manage sprints
* Allows adding and updating sprints
* Allows adding and removing work packages (within sprint buckets)
* Allows defining the order of work packages within the sprint bucket
* Replaces the current "Update sprints"
* Start and complete sprint (use case: this role would be relevant for SAFe teams or large organizations where sprints should be managed centrally. Interesting especially while sharing sprints.)
* Allows starting a new sprint
* Allows completing an active sprint
* View sprints
* \[open\] copied from the epic. What is the permission necessary for? Seeing the sprint is definitely necessary whenever backlogs is to be used.
* \[open\] There is an "Assign versions" permission that is required when wanting to connect work packages and versions. Do we want the same for sprints? This would allow a role like a "Product owner" in Scrum. Scrum.
**Translation considerations**
* _Key terms and phrases in the key 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, and easily reorganise sprints by moving items between them (and the backlog)
**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 the project it is defined in.
* subprojects - The sprint is available in the project it is defined in and its subprojects (use case: for SAFe ART users will create a project on the portfolio or program level and will be able to pass it on to all subprojects)
* all projects/systemwide - The sprint is available in all projects of the instance.
* a name (plain text) - same across all shared with projects
* we automatically set a name when a user creates a sprint bucket "Sprint 1"
* user can overwrite the name
* for each new bucket we count +1 based on the latest sprint bucket, copying the text part of the sprint name used for the latest sprint, e.g. the one edited by the user
* if user removed the digits in all sprint names in planning, we stop counting
* a start and a finish date (dates) - same across all shared with projects
* a status - same across all shared with projects. The list of status is a fixed set:
* In planning
* Active
* Completed
* The user can connect a work package to a sprint. A sprint can be associated to multiple work packages.
* For now, this is only possible within the Backlog module. <mention class="mention" data-id="71061" data-type="work_package" data-text="##71061">##71061</mention> will add an editable and manageable "sprint" field to work packages.
* The "sprint" property is journaled.
* Work packages have a "position" field to remember the order within the sprint. This field already exists and is left untouched.
* Sprints will later on be exposed via an API (see #71058 and #71061)
* 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).
* The button reading "+ Version" is changed to "+ Sprint" and [opens
* 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 item will be removed (later on possibly readded by #71061).
* 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**
* Migration considerations:
* 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 is migrated
* \[open\] Mapping of status
* The project the sprint is created in and the sharing it has:
* The project furthest down the hierarchy with the sharing set to "subprojects" - if the sprint is used in multiple projects and they share the same hierarchy
* Just the project where the sprint is used with the sharing set to "none" - if the sprint is only used in a single project.
* The project having the "system-wide" version defined with the status set to systemwide - for a version shared system-wide.
* The existing connection from a work package to a version is kept
* The reason for this is that we cannot differentiate programmatically 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.
* A journal is written by the system user informing about the shift from version to sprint - no notification is sent
* \[open\] Phrasing of the message
* Permissions need to be migrated (see below)
**Permissions and visibility considerations**
* Manage sprints
* Allows adding and updating sprints
* Allows adding and removing work packages (within sprint buckets)
* Allows defining the order of work packages within the sprint bucket
* Replaces the current "Update sprints"
* Start and complete sprint (use case: this role would be relevant for SAFe teams or large organizations where sprints should be managed centrally. Interesting especially while sharing sprints.)
* Allows starting a new sprint
* Allows completing an active sprint
* View sprints
* \[open\] copied from the epic. What is the permission necessary for? Seeing the sprint is definitely necessary whenever backlogs is to be used.
* \[open\] There is an "Assign versions" permission that is required when wanting to connect work packages and versions. Do we want the same for sprints? This would allow a role like a "Product owner" in Scrum.
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* Having a sprint board (for now)