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.
Things to keep in mind if you migrate ( team –> company): Custom fields
custom fields in your team-managed project–> jira admin needs to recreate them
Custom field data will need to be recreated, otherwise it will be lost.
Things to keep in mind if you migrate ( team –> company): Issue types
custom issue types will need to be recreated
Things to keep in mind if you migrate ( team –> company): Project and issue keys
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 ( team –> company): Reports
Reports data won’t be saved.
Things to keep in mind if you migrate ( team –> company): Story points estimation
will be lost
custom field that Jira uses to store estimates in company-managed projects (Story points) is different to the custom field used in team-managed projects (Story point estimate)
Features in company managed projects
Jira couples features with the project template used to create a project. Once you’ve picked a template, you’re locked into the features that come with it.
Features in team managed projects
you can enable and disable different features to suit your team’s needs.
Settings in team managed projects
teams set up and manage their workspace independently.
They update their project’s settings without the help of a Jira administrator.
These projects are ideal for teams who want to try different working methods as they mature.
Settings in company managed projects
Jira administrators set up and manage a team’s workspace.
Teams ask a Jira administrator to update their project’s settings.
Company-managed projects help organizations promote and enforce best practices across many teams.
What are the project templates?
Kanban
Scrum
Bug Tracking
Kanban Project Template
Choose the kanban template to help teams visualize their work, limit work currently in progress, and maximize efficiency.
Work is continuously delivered in kanban, and your team pulls single pieces of work from the backlog, and then moves them to done.
Scrum Project Template
Choose the scrum to work in a series of fixed-length iterations (sprints) that give teams a framework for shipping on a regular cadence.
Bug tracking
manages a list of development tasks and bugs.
It’s best suited for teams that are capturing, tracking, and resolving bugs.
What can be impacted by a change of Project lead in the project settings ?
- component asignments
- permissions
- notifications
- workflow conditions
- security levels
What must be associated with a project to allow for issue tracking and customization?
1 - A Workflow Scheme
2 - A Field Configuration Scheme
3 - A Permission Scheme
4 - All of the above
- All of the above
Your Jira cloud instance has hundreds of projects which are used only by the development team at
your organization.
All projects share a single permission scheme New business requirements state:
● Customer support staff at your organization need to view all issues in all projects
● They also need to share filters with other users
● They should not be granted too much access
Identify the appropriate way to configure customer support staff in Jira (Choose one)
A. As a security level
B. As a new project role
C. As a new group
D. With the Trusted role
E. With an approved domain
Answer: C
Project Types
- Buisness ( core jira finctionality )
- software ( board releasehub, agile reports)
- Service Management ( Queues, SLA’s, knowledge base integration, customer portal, request types)
Pros of shared schemes:
- easy to manage
- changes apply to all projects
- standardizatiosn
- little impact on performance
Cons of shared schemes:
- Limited flexibility
- multiple stakehoders must be consulted
- potential errors, side effects impacting other projects
Pros of Unique schemes
- satisfy specific requirements
- modifying the scheme doesnt impact other projects
Cons of unique schemes
- Administrative overhead
- impact on performance
- careful management required for many schemes
Team-managed project board:
- Users can create multiple issues from the board.
- Users can create a new status from the board.
- Users can group the issue by priority.
Resolution field
Not supported by team managed projects
What needs to be checked if a resolution is changed? ( for example form done to completed)
Similar to changing the status name, changing the resolution name will impact the JQL results.
so need to check:
1. automation rules
2. filters
3. dashboards
4. reports
Team-managed project:
You have 10** issues** in version 1.0 and 1 issue in version 1.0x. Due to the incorrect version name, you wants to merge version 1.0x to version 1.0.
What do you need to do ?
- Move
- Delete
Archiving is not an option as it doesnt allow the moving of the issues.
There are no Merge or Swap actions in Releases.
In the ** Software development project **BOARD, users can only group issues by:
- Assignee
- Epic
- Subtasks
In a Work management project users can only group issues by:
- Status
- Category
- Assignee
- Priority
Team-managed project board facts:
Users can group the issue by asignee.
Users can rename the status from the board.
Users can group the issue by subtask.
Users do not need to create a new status from the project workflow.
The new status will be created after users add a new column on the team-managed project board.
