Content
View differences
Updated by Jens Ulferts 2 months ago
**As** a product owner
**I want to** group work packages into backlog buckets and prioritize them against each other
**so that** backlog grooming is possible even with a large set of work packages
**Acceptance criteria**
* Backlog buckets are lists of work packages.
* They have a user provided name.
* The "Sprint planning" view shows backlog buckets.
* The name and the number of work packages within the bucket are displayed.
* Users can sort the items in a backlog bucket via drag & drop and via menu entries.
* A work package can
* only be in a single backlog bucket at a time.
* cannot be in a backlog bucket and a sprint at the same time.
* cannot be in a backlog bucket and the "inbox" backlog bucket at the same time
* Users can move a work package into a backlog via a menu entry in
* Sprints
* "Inbox" backlog bucket
* Another backlog bucket
* The user can toggle between each bucket and the "Inbox" backlog bucket (###72198) using a select.
* The version based backlogs are completely replaced by this feature
* The setting "Column in backlogs" is removed in the version administration (###72800)
* A backlog bucket can be created on the view via the "+ Backlog bucket" on the page.
* Clicking on the button opens a modal in which the name can be selected
* Backlog buckets can be deleted via a menu entry in the bucket menu
* Buckets can be renamed via a menu entry in the bucket menu
* A modal opens in which the user inserts the new name.
* Buckets are only present within the project in which they were created. There is no sharing of them for now.
* Migration of versions configured to be backlog buckets:
* For every version configured to be displayed right in the "Column in backlog" setting create a bucket with the version's name in a project if:
* There is at least a single non closed work package in the version in that project.
* The result of the above is that there can be multiple, distinct backlog buckets in different projects where before a shared version was used.
* Migrated versions are left unchanged. They are not deleted, nor is their sharing setting changed.
<br>
**Technical notes**
* <br>
**Permissions and visibility considerations**
* Creation/Deletion of buckets requires the `create_sprints` permission
* Moving a work package into/out of a bucket requires the `manage_sprint_items` permission
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* The backlog a work package is in is for now not visible on the work package itself (subject to change)
* The backlog property is for now not part of the work packages API. There is also no other API for the buckets for now.
* For now, it is not possible to display multiple backlog buckets at the same time on the "Sprint planning" page.
* Creation of work packages inside a backlog bucket is not yet possible (subject to change)
**I want to** group work packages into backlog buckets and prioritize them against each other
**so that** backlog grooming is possible even with a large set of work packages
**Acceptance criteria**
* Backlog buckets are lists of work packages.
* They have a user provided name.
* The "Sprint planning" view shows backlog buckets.
* The name and the number of work packages within the bucket are displayed.
* Users can sort the items in a backlog bucket via drag & drop and via menu entries.
* A work package can
* only be in a single backlog bucket at a time.
* cannot be in a backlog bucket and a sprint at the same time.
* cannot be in a backlog bucket and the "inbox" backlog bucket at the same time
* Users can move a work package into a backlog via a menu entry in
* Sprints
* "Inbox" backlog bucket
* Another backlog bucket
* The user can toggle between each bucket and the "Inbox" backlog bucket (###72198) using a select.
* The version based backlogs are completely replaced by this feature
* The setting "Column in backlogs" is removed in the version administration (###72800)
* A backlog bucket can be created on the view via the "+ Backlog bucket" on the page.
* Clicking on the button opens a modal in which the name can be selected
* Backlog buckets can be deleted via a menu entry in the bucket menu
* Buckets can be renamed via a menu entry in the bucket menu
* A modal opens in which the user inserts the new name.
* Buckets are only present within the project in which they were created. There is no sharing of them for now.
* Migration of versions configured to be backlog buckets:
* There is at least a single non closed work package in the version in that project.
* The result of the above is that there can be multiple, distinct backlog buckets in different projects where before a shared version was used.
* Migrated versions are left unchanged. They are not deleted, nor is their sharing setting changed.
**Technical notes**
* <br>
**Permissions and visibility considerations**
* Creation/Deletion of buckets requires the `create_sprints` permission
* Moving a work package into/out of a bucket requires the `manage_sprint_items` permission
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* The backlog a work package is in is for now not visible on the work package itself (subject to change)
* The backlog property is for now not part of the work packages API. There is also no other API for the buckets for now.
* For now, it is not possible to display multiple backlog buckets at the same time on the "Sprint planning" page.
* Creation of work packages inside a backlog bucket is not yet possible (subject to change)