Content
View differences
Updated by Jens Ulferts about 12 hours 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 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
* These dates are mostly optional. Their presence is required and validated when the sprint is about to be started or active.
* 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. Multiple work packages can be associated with a sprint.
* 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 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").
* 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 rea-dded 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 (for now).
* The task board will use the sprint
* The burndown chart will use the sprint
* Sprints can be shared
* **For 17.2** the Versions are migrated Sprints first, so we don't lose data.
* Mapping Versions to Sprints:
* Not Shared -> Not Shared
* With Subprojects -> With Subprojects
* With Project Hierarchy -> With Subprojects
* Simulate Hierarchy by finding the root Project and apply sharing with Subprojects. As a side effect, the sprint will be shared with the original Projects' sibling as well.
* With Project Tree -> With Subprojects
* Finding root Project, same as Hierarchy.
* All Projects -> All Projects
* **After 17.2** Sharing is a project-level setting, not a sprint-level one (as is the case with versions at the moment). Users can choose in the project settings:
* Share sprints - Sprints can be created in this project (enable/disable). Sprints created in the project are then shared with either (user selection):
* All projects
* Subprojects
* No sharing - Sprints can be created in this project. None of the created sprints are shared with any other project
* Receive shared sprints - No sprints can be created within this project. Instead shared sprints are used.
* Only one project in the instance can "Share with all projects".
* In the scope _\[open\] Possibly, define system-wide sprints not within a project but outside of <mention class="mention" data-id="71890" data-type="work_package" data-text="###71890">###71890</mention> those sprints are moved to the it. It could then be guarded by a global backlog module. permission._
* Sprint sharing is only possible if enabled first in the instance administration
* _\[open\] This is possibly them most logical location for the "Share with all projects" setting_
* Only sprints from one sharing project are received. If there are multiple projects from which a receiving project could take its sprints the order of priority is as follows (lowest to highest priority):
* All projects sharing
* Subproject sharing higher up the ancestor chain
* Subproject sharing lower down the ancestor chain
* Status, name and dates of a sprint are also shared (can't be different per project)
**Technical notes**
* Migration considerations:
* Existing versions used as sprints are migrated (read copied).
* 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 are migrated
* Mapping of status
* Version open -> Sprint in planning
* Version locked or closed -> Sprint completed
* The project the sprint is created in and the sharing it has:
* _\[open\] Needs to be defined_
* 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: "Version '{version name} has been converted to a sprint."_
* Permissions need to be migrated:
* View master backlog → View sprints
* View taskboards → View sprints
* Select done statuses (remove later on or remove the functionality with it)
* Update sprints → _(remove, but to be confirmed)_
* Manage versions → Create sprints (?)
* Assign versions → (split) Manage sprint items
**Permissions and visibility considerations**
* Backlogs needs to be activated for any of the permissions to work
* View sprints
* Allows accessing backlogs
* Allows seeing sprints on work packages (once that feature is developed)
* Allows accessing the burndown chart
* This permission is a dependency for all the other permissions below. This is coded in.
* Create sprints
* Allows adding/updating/deleting sprints including name, dates but excluding status. Allows to configure whether to receive or to not receive shared sprints in the project configuration.
* Start/complete sprint
* Allows changing the status of the sprint
* Manage sprint items
* Allows adding and removing from a sprint, and re-ordering of items
* Share sprint
* Allows to configure sharing (all projects or sub-projects) in the project configuration
* Depends on the user having the "Create sprints" permission.
**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 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
* These dates are mostly optional. Their presence is required and validated when the sprint is about to be started or active.
* 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. Multiple work packages can be associated with a sprint.
* 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 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").
* 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 rea-dded 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 (for now).
* The task board will use the sprint
* The burndown chart will use the sprint
* Sprints can be shared
* **For 17.2** the Versions are migrated Sprints first, so we don't lose data.
* Mapping Versions to Sprints:
* Not Shared -> Not Shared
* With Subprojects -> With Subprojects
* With Project Hierarchy -> With Subprojects
* Simulate Hierarchy by finding the root Project and apply sharing with Subprojects. As a side effect, the sprint will be shared with the original Projects' sibling as well.
* With Project Tree -> With Subprojects
* Finding root Project, same as Hierarchy.
* All Projects -> All Projects
* **After 17.2** Sharing is a project-level setting, not a sprint-level one (as is the case with versions at the moment). Users can choose in the project settings:
* Share sprints - Sprints can be created in this project (enable/disable). Sprints created in the project are then shared with either (user selection):
* All projects
* Subprojects
* No sharing - Sprints can be created in this project. None of the created sprints are shared with any other project
* Receive shared sprints - No sprints can be created within this project. Instead shared sprints are used.
* Only one project in the instance can "Share with all projects".
* In the scope
* Sprint sharing is only possible if enabled first in the instance administration
* _\[open\] This is possibly them most logical location for the "Share with all projects" setting_
* Only sprints from one sharing project are received. If there are multiple projects from which a receiving project could take its sprints the order of priority is as follows (lowest to highest priority):
* All projects sharing
* Subproject sharing higher up the ancestor chain
* Subproject sharing lower down the ancestor chain
* Status, name and dates of a sprint are also shared (can't be different per project)
**Technical notes**
* Migration considerations:
* Existing versions used as sprints are migrated (read copied).
* 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 are migrated
* Mapping of status
* Version open -> Sprint in planning
* Version locked or closed -> Sprint completed
* The project the sprint is created in and the sharing it has:
* _\[open\] Needs to be defined_
* 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: "Version '{version name} has been converted to a sprint."_
* Permissions need to be migrated:
* View master backlog → View sprints
* View taskboards → View sprints
* Select done statuses (remove later on or remove the functionality with it)
* Update sprints → _(remove, but to be confirmed)_
* Manage versions → Create sprints (?)
* Assign versions → (split) Manage sprint items
**Permissions and visibility considerations**
* Backlogs needs to be activated for any of the permissions to work
* View sprints
* Allows accessing backlogs
* Allows seeing sprints on work packages (once that feature is developed)
* Allows accessing the burndown chart
* This permission is a dependency for all the other permissions below. This is coded in.
* Create sprints
* Allows adding/updating/deleting sprints including name, dates but excluding status. Allows to configure whether to receive or to not receive shared sprints in the project configuration.
* Start/complete sprint
* Allows changing the status of the sprint
* Manage sprint items
* Allows adding and removing from a sprint, and re-ordering of items
* Share sprint
* Allows to configure sharing (all projects or sub-projects) in the project configuration
* Depends on the user having the "Create sprints" permission.
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* Having a sprint board (for now)