General Project Configuration Flashcards
When to choose team managed projects?
- Your team wants easier project configuration to get started quickly.
- You want a self-contained space to manage your team’s work.
Choose a company-managed project if you:
- want to standardize configuration across multiple projects in your organization
- want complex customization with regard to permissions and workflow.
What schemes are shared when a new project is made?
- Field Configuration Scheme
- Permission Scheme
- Notification Scheme
What schemes are unique when a new project is made?
- Issuetype Scheme
- Issue type screen scheme
- Workflow scheme
Components
Affect Version Field
Releases
Custom Fields
Custom Resolutions
Which of these cannot be used/done in Team Managed Projects?
Components, Affect Version Field, Custom Resolution
Which project type can you release a version via the board?
company managed kanban board
What happens to issues when you delete their fix version?
- reference to that version will be deleted
- you can select a new version
What actions can you perform on versions
delete, merge, release, archive, unarchive
Archived versions can be searched but not selected
Migration between team to company steps (or the other way round):
- Create a new team-managed project to receive your existing company-managed project issues
- Find and move your existing issues to your new project
How can you move existing issues into a new project?
Bulk change issue –> move issue –> select any required fields –> confirm –> acknowledge
Things to keep in mind if you migrate from company-managed to team-managed: Sprints
Sprints won’t move from company-managed project to a team-managed
Past sprints will not be displayed on the timeline.
Issues that were in your company-managed project will be added to the BACKLOG of your team-managed project.
Things to keep in mind if you migrate ( company –> team ) : Components
Component fields are unique to every project in Jira.
If you migrate issues with completed component field information, you will lose this data.
Components field data is not recoverable, even if you bulk move these issues back to the company-managed projects they came from.
Things to keep in mind if you migrate ( company –> team ): Custom fields
- Must be recreated in your new team-managed project.
- Global custom field values are retained (except component and version fields) BUT they aren’t mapped to your team-managed project’s fields.
- The fields in your company-managed project are technically different from the fields in your team-managed destination, so they will appear blank.
- If you move Issues back to a company-managed project that supports the custom field, the original values stored against it reappear.
Things to keep in mind if you migrate ( company –> team ):
Story points estimation
This data will be lost.
You can enable the Estimation feature in your team-managed project.
Things to keep in mind if you migrate ( company –> team ):
Reports
Data won’t be saved.
The Velocity report will show that no points were completed in past sprints.
Things to keep in mind if you migrate ( company –> team ):
Report history
All reporting history is lost in this migration process.
The Burnup report and Velocity report won’t be migrated.
Things to keep in mind if you migrate( company –> team ):
Parallel sprints
unsupported in team managed
Things to keep in mind if you migrate( company –> team ):
Project and issue keys
Jira will automatically update the issue keys of migrated issues to reflect their new project.
Any existing links to old issue keys will be automatically redirected.
Things to keep in mind if you migrate( company –> team ):
Versions and releases
Any version information is lost in this migration process, even if you have the Releases and versions feature enabled in your new team-managed project.
Things to keep in mind if you migrate ( team –> company): Board statuses
customized your team-managed board –> set up the same statuses in your company-managed project’s workflow.