**As** a user following agile methodologies
**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

**Acceptance criteria**

* Begin of the deletion The feature is hidden behind a feature flag

* Unless it is used by the existing Backlogs module

* End of the deletion Sprints exist in OpenProject. They have

* a name (plain text)

* a start and a finish date (dates)

* a goal (plain text)

* a status

* \[Open\] will this status have fixed values or can the user administrate (add/remove/order)?

* a capacity

* story points or days

* \[open\] will we support both from the start? Begin of the insertion

End of the insertion Begin of the deletion

End of the deletion * Begin of the insertiona number of projects they are shared with

* \[Open\] Should the same options be used as for versions?

* End of the insertion Work packages can be connected to multiple sprints.

* The sprint property can be administrated in the form configuration.

* The property can be used to filter, sort and group in the work package list. Begin of the insertion

End of the insertion Begin of the deletion

End of the deletion * Begin of the insertionThe property is journaled.

* \[Open\] it might be sufficient to connect a work package to a single sprint. My \[Jens\] understanding is, that a user should be able to see which sprints a work package has been assigned to in its history. We can get that information from the journals. It will already be displayed in the activity but we could also show it differently, e.g. in a hover card over the current sprint value.

* If a work package can be connected to multiple sprints, the position within each need to be kept independently. There is currently a "position" field added to work packages by backlogs.

* End of the insertion Sprints are exposed via an API. Begin of the insertion

End of the insertion Begin of the deletion

End of the deletion * Begin of the insertionSprints are part of the work package API (resource, form, schema including available values)

* End of the insertion \[open\] Begin of the insertionis there a list of sprints (filterable by project)?

* This would be necessary for the mobile app

* \[open\] Can sprints be created, updated and deleted via the API?

* End of the insertion Versions are no longer used by the existing Backlogs module. Sprints are used instead.

* Begin of the insertionOnlyEnd of the insertion Begin of the deletion This will only be necessary ifEnd of the deletion the Begin of the insertionleft hand part of the backlogs main view will use sprints.End of the insertion Backlogs Begin of the insertion(currently displayed to the right) will continue to use versions (subject to change later).End of the insertion Begin of the deletion module is continued and not replaced by a new agile moduleEnd of the deletion

* Existing versions used as sprints are migrated. Begin of the insertion

End of the insertion Begin of the deletion

End of the deletion * Begin of the insertionThe goal is to have an uninterrupted user experience when switching from the pre-sprint state to the post-sprint state.

* A version is migrated if

* the version is configured toEnd of the insertion Begin of the deletion \[open\] Can sprintsEnd of the deletion be Begin of the insertiondisplayed "left" (for "Column in backlog") in at least one project

* the version has at least one work package associated to it in a project in which the version is configured to be displayed "left"

* The existing connection from a work package to a version is kept

* Work packages associated to a migrated version are associated to the created sprint.

* The button reading "+ Version" is changed to "+ Sprint" and opens the sprint creation form.

* 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 will lead to the work package list filtered by the sprint.

* The version form no longer has the "Column in backlogs" select field. Instead a "UsedEnd of the insertion Begin of the deletion shared sameEnd of the deletion as Begin of the insertionbacklog" checkbox is displayed.

End of the insertion Begin of the deletion versions currently can (e.g. hierarchy or whole instance).

End of the deletion * Begin of the insertionThe limitation on the work package type (which type qualifies as a user story, which one is a task) remains unchanged.

* The task board willEnd of the insertion Begin of the deletion \[open\] How can sprintsEnd of the deletion be Begin of the insertionusing the sprint

* The burndown chart (if it still exists) will be using the sprint


End of the insertion Begin of the deletion administrated?


End of the deletion **Technical notes**

* <br>


**Permissions and visibility considerations**

* _To whom is this feature visible?_

* _When is it not visible?_


**Translation considerations**

* _Key terms and phrases in the key languages_&nbsp;


**Out of scope**

* Having a sprint board (for now)