Content
View differences
Updated by Attila Dombi about 16 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
* 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
* Receive shared sprints - No sprints can be created within this project. Instead shared sprints are used.
* No sharing - Sprints can be created in this project. None of the created sprints are shared with any other project
* This is the default setting for projects
* Only one project in the instance can "Share with all projects".
* In the scope of <mention class="mention" data-id="71890" data-type="work_package" data-text="###71890">###71890</mention> those sprints are moved to the global backlog module.
* Sprint sharing is only possible if enabled first in the instance administration _(only in 17.4) (See <mention class="mention" data-id="72775" data-type="work_package" data-text="###72775">###72775</mention> )_
* _\[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
* As long as there is a work package associated to the sprint, the sprint is displayed in the work package's project. That is true even if the sprint is not shared with the project (any more). The sprints can be used just like any other sprint.
* 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_
* Set all Project sharing option to "Receive shared sprints" by default.
* Take all the Versions and iterate their sharing settings:
* When Version is "Share with All Projects" -> Set the Project to "Share Sprint in All Projects"
* When Version is "Share with Subprojects" ->
* If Project is "Share Sprint in All Projects" -> Do nothing
* Else -> Set the Project to "Share with Subprojects"
* When Version is "Share with Hierarchy" or "Share with Tree" ->
* Move up to the root Project of the hierarchy and set the Sprint Project to the root Project.
* If root Project is "Share Sprint in All Projects" -> Do nothing
* Else -> Set the root Project to "Share with Subprojects"
* When Version is "Share with None" ->
* Do nothing.
* 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
* 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
* Receive shared sprints - No sprints can be created within this project. Instead shared sprints are used.
* No sharing - Sprints can be created in this project. None of the created sprints are shared with any other project
* This is the default setting for projects
* Only one project in the instance can "Share with all projects".
* In the scope of <mention class="mention" data-id="71890" data-type="work_package" data-text="###71890">###71890</mention> those sprints are moved to the global backlog module.
* Sprint sharing is only possible if enabled first in the instance administration _(only in 17.4) (See <mention class="mention" data-id="72775" data-type="work_package" data-text="###72775">###72775</mention> )_
* _\[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
* As long as there is a work package associated to the sprint, the sprint is displayed in the work package's project. That is true even if the sprint is not shared with the project (any more). The sprints can be used just like any other sprint.
* 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_
* Set all Project sharing option to "Receive shared sprints" by default.
* Take all the Versions and iterate their sharing settings:
* When Version is "Share with All Projects" -> Set the Project to "Share Sprint in All Projects"
* When Version is "Share with Subprojects" ->
* If Project is "Share Sprint in All Projects" -> Do nothing
* Else -> Set the Project to "Share with Subprojects"
* When Version is "Share with Hierarchy" or "Share with Tree" ->
* Move up to the root Project of the hierarchy and set the Sprint Project to the root Project.
* If root Project is "Share Sprint in All Projects" -> Do nothing
* Else -> Set the root Project to "Share with Subprojects"
* When Version is "Share with None" ->
* Do nothing.
* 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)