Content
View differences
Updated by Jens Ulferts 22 days 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 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 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 (for now). unchanged.
* The task board will be using the sprint
* The burndown chart will be using the sprint
* Sprints can be shared
* Sharing is a project-level setting, not a sprint-level one (like with versions at the moment). Users can choose in the project settings:
* Share sprints - Sprints can be created in this project. All those created sprints are shared to 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.
* Status, Name and dates of a sprint are also shared (can't be different per project)
* Only one project can "Share with all projects".
* \[open\] Possibly, define systemwide sprints not within a project but outside of it. It could then be guarded by a global permission.
* Sprint sharing is only possible if enabled first in the instance administration
* 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
**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 is 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 The project furthest down the hierarchy with the sharing set to be &quot;subprojects&quot; - 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 &quot;none&quot; - if the sprint is only used in a single project.
* The project having the &quot;system-wide&quot; 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:
* 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
migrated (see below)
**Permissions and visibility considerations**
* Backlogs needs to be activated for any of If backlogs is activated, all users having the permissions to &quot;View work packages&quot; permission can access backlogs and can see the sprints and backlogs and their contents.
* View Manage sprints
* Allows accessing backlogs
* Allows seeing adding and updating sprints on work packages (once that feature is developed)
* Allows accessing Replaces the burndown chart current &quot;Update sprints&quot;
* This permission is Allows starting a dependency for all the other permissions below. This is coded in.
new sprint
* Create sprints
<mention class="mention" data-id="71386" data-type="work_package" data-text="###71386">###71386</mention>
* 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 adding and removing work packages (within sprint
buckets)
* Allows changing defining the status order of work packages within the sprint
bucket
* Manage ~~Start and complete sprint items (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 adding and removing from ~~Allows starting a sprint, and re-ordering of items
* Share sprint
* Allows to configure sharing (all projects or sub-projects) in the project configuration new sprint~~
* Depends on the user having the "Create sprints" permission. ~~Allows completing an active sprint~~
**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
* 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
* 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 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 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 (for now).
* The task board will be using the sprint
* The burndown chart will be using the sprint
* Sprints can be shared
* Sharing is a project-level setting, not a sprint-level one (like with versions at the moment). Users can choose in the project settings:
* Share sprints - Sprints can be created in this project. All those created sprints are shared to 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.
* Status, Name and dates of a sprint are also shared (can't be different per project)
* Only one project can "Share with all projects".
* \[open\] Possibly, define systemwide sprints not within a project but outside of it. It could then be guarded by a global permission.
* Sprint sharing is only possible if enabled first in the instance administration
* 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
* 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
* 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
* Just the project where the sprint is used with the sharing set to &quot;none&quot; - if the sprint is only used in a single project.
* The project having the &quot;system-wide&quot; version
* 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:
* 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
* Backlogs needs to be activated for any of
* View
* Allows accessing backlogs
* Allows seeing
* Allows accessing
* This permission is
* Start/complete
* Allows adding and removing from
* 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)