Jira Introduction for Jira Project Leads
Welcome Project lead, to a brief introduction to Jira and your responsibilities and options as Jira Project Leader (JPL). As JPL you are responsible for all activities within your projects. This includes all on-boarding and off-boarding processes as well as making sure your project is maintained in a way that ensures that no performance impacts can occur. As your responsibility is quite big, you are also eligible for training and support.
The JPL have full responsibility of his or her project. This means that anything happening within the project will fall on the JPL. This includes performance issues due to wrong setup or usage of fields, flows, boards and filters. It also includes on-boarding new users and of course off-boarding to ensure that no users that should no longer have project access still linger within your project.
As the JPL you are also responsible for ensuring that your team or, teams, can work in an optimal way. This includes helping them to setup and operate boards, sprints and so on. You may not be the person who actually do this on a day to day basis, but you need to know how to support the members of your project should they need it.
You are also responsible to ensure that the project specific functions for versions and components are maintained correctly. That includes to archive versions no longer being used and ensure that the setup of components are used according to standards to allow for cross functionality and integration sanity.
The JPL is the first contact, and often only contact, when issues occur in Jira. As the contact person the JPL is required to be a member of the Jira Teams as well as keeping updated regarding news on the Jira SharePoint site.
In the event of an issue with Jira as a whole, or even more important an issue with the project the JPL is responsible for the JPL should be able to respond within a reasonable time frame. Failure to respond could lead to a shutdown of the project.
If a JPL is no longer active the project can be shut down until a JPL is assigned. This is because we cannot have a project without a responsible person owning it. A person must be contactable should anything happens that require action from the JPL.
On-boarding a Project
On-boarding a project is done by making sure the correct setup has been added during creation. This is done by accessing the project settings and reviewing the settings. If the settings are not correct it could cause serious problems working in Jira for the whole team.
During the project creation it is also up to the JPL to verify that the workflows and other settings are not only correct, but also suitable for the team to work with. If the way of working can benefit from customization than this can be discussed with the Jira team.
Customizations are exceptions and require an obvious improvement to the workflows of the team.
Off-boarding a project
When a project is no longer needed it need to be archived. This is done by sending a request to the Jira team. Doing this will make the project read only for a year and then hidden for a year before it is deleted.
When a project is archived it will no longer show up in searches. All issues in the project will also be hidden from searches. This reduce the number of items that show up in searches, which in turn will reduce the number of items that need to be fetched from the database. This help performance and reduce clutter in Jira.
Handling users is done by adding or removing users manually in the Roles section.
When a user is added to the Jira project it is the responsibility of the JPL to ensure that the users have the knowledge and understanding of how to work in Jira. As the JPL this responsibility cannot be put of someone else and if a user cause incident in Jira due to not understanding the way of working or how Jira works, that is on the JPL.
For this reason, it is suggested that new members get proper training within the project or by attending a Jira training session.
Each user uses a license in Jira and as such it's very important to not let users accounts remain after they have left. It's the JPL who is responsible for keeping their members up to date as they also are responsible for the license cost of their project.
Versions are important parts of Jira as it is the way we can determine in what code base development or configures has been committed. Version are created and managed by the JPL and project managers, which means that the responsibility with releasing and archiving versions also fall on the JPL.
Once a version no longer is required to connect defects to that version should get closed. This is done by the JPL and the project managers. If this is not done properly the list of versions will grow exponentially, which causes issues for the project and potentially for Jira as a whole.
Components are used for additional grouping for Jira issues within a project. While this is a very useful feature it's also important to remember that components are project specific and if you work cross projects then a moved issue can lose this information.
It is the responsibility of the JPL and the project managers to manage the components and make sure it's used on a level that cannot be compromised if an issue moves to another project. For this reason, components should not contain issue critical information.
Performance impact decisions
Decisions within the project, like adding new custom fields or values within a custom field, custom workflows or filters for boards also fall under the responsibility of the JPL. For this reason, it's important to understand the impact new fields, filters and so on have on the project as well as on Jira as a whole.
Should a project become slow due to performance issues or worse, if all of Jira would suffer due to decisions that lead to performance issues, that is on the JPL. For this reason, it's no excuse to claim ignorance as failure in this regard can cause severe impact and possibly legal actions.
As JPL it is strongly suggested to consult the Jira team if you wish to adjust your project that you are unsure if it can impact performance.
Day to Day operations
The JPL should have knowledge on how to do the basic day to day operations. This includes creation of sprints, setting up boards, working with filters and backlogs as well as the JPL specific tasks of managing components and versions.
The JPL are the owner of your project and as such the JPL should know how Jira works so they can guide the members of the project on a daily basis. The JPL are not expected to be an expert but should know the basics.
For this reason, all JPL's should attend the JPL training before starting their project. It's also suggested to attend at least one JUT training session and all JST training available.
While it might sound like a JPL have a lot of responsibilities they also have a lot of possibilities. Not only will the JPL have access to the JPL trainings, they also have the possibilities to request support and guidance from the Jira team.
Besides access to the JPL training sessions all JPL's have the option to request support from the Jira team for specific training sessions. This can be anything from an extra JUT session or it can be a full-fledged JST with custom content specifically designed for the need of the JPL and the project team.
At any time can the JPL request assistance on Jira matters from the Jira team through Teams.
All projects are not equal, but in Jira they all follow the same structure. For this reason, it is sometimes necessary to make customizations to improve the quality of work or improve efficiency. The JPL can request a consultation with the Jira team to discuss a solution to achieve this that is best suited for the project as well as for the system as a whole.
Common requests are custom fields to add more information inside Jira, custom workflows for situations when the standard flows no longer apply and custom screens for displaying certain type of information differently.
Since these requests cause a strain on performance they need to be carefully considered and designed so they can be used by many and not be project unique only. All customizations must be requested by the JPL and it must be approved by the Jira team before it can be added to the system setup.
Plugins is a special request that also can be initiated by the JPL, but as plugins have a much higher degree of maintenance it cannot be approved by the Jira team alone. All plugins follow the demand process where it will go through an approval board. It is up to the JPL to define why a plugin should be added to Jira and to secure the finances to pay for it.