How to become a Jira Super User
How to become a Jira Super User
How to become a Jira Super User
Aug 14, 2015



In the examples above, we can see that equating a JIRA project with a business effort, or project, can work well… for a time. In the beginning (example 1) things ran smoothly for HealthFacts because there team was uniform and the project settings were simple, but when the company began to grow things became more complicated. They started experiencing problems with the system and began to find it difficult to find information. All of their problems could have been prevented with better organization
Every single project for the newsletter is identical to every other newsletter project except for the name and the tasks within. Every time a new project is created the same information and settings are copied from the older project. There is no need to have multiple projects when the setting of those projects is identical. Creating new projects, like in example 2, creates management overhead and could potentially create a security risk. Also, every time a new project is created it creates work for the administrators and creates the potential for an error to occur during the creation. If the newsletter team has used a single project for every newsletter they would not have an issue with the project settings as they did in example 2.
In example 3, the projects ended up impeding the user’s ability to find an issue rather than enhance it. The more projects there are, the more projects one must search through in order to research a past issue. Notice that Mary did not even use the project in her search criteria in example 3. If she had, they would not have been able to find the issue at all since it wasn’t in the project the assumed it would be in. Relying on the project could limit the scope of a user’s search, often times the project is not even utilized when searching.
It seems that the only real benefit of the numerous project method is it can make visual issue browsing more convenient. This is only true for very small projects. JIRA will only list 50 issues on a page; most projects will have more than 50 issues in them. Once a user needs to start paging through long lists of issues in a project, visual browsing becomes a very ineffective way to search and should not be the basis behind creating new projects.

In the examples above, we can see that equating a JIRA project with a business effort, or project, can work well… for a time. In the beginning (example 1) things ran smoothly for HealthFacts because there team was uniform and the project settings were simple, but when the company began to grow things became more complicated. They started experiencing problems with the system and began to find it difficult to find information. All of their problems could have been prevented with better organization
Every single project for the newsletter is identical to every other newsletter project except for the name and the tasks within. Every time a new project is created the same information and settings are copied from the older project. There is no need to have multiple projects when the setting of those projects is identical. Creating new projects, like in example 2, creates management overhead and could potentially create a security risk. Also, every time a new project is created it creates work for the administrators and creates the potential for an error to occur during the creation. If the newsletter team has used a single project for every newsletter they would not have an issue with the project settings as they did in example 2.
In example 3, the projects ended up impeding the user’s ability to find an issue rather than enhance it. The more projects there are, the more projects one must search through in order to research a past issue. Notice that Mary did not even use the project in her search criteria in example 3. If she had, they would not have been able to find the issue at all since it wasn’t in the project the assumed it would be in. Relying on the project could limit the scope of a user’s search, often times the project is not even utilized when searching.
It seems that the only real benefit of the numerous project method is it can make visual issue browsing more convenient. This is only true for very small projects. JIRA will only list 50 issues on a page; most projects will have more than 50 issues in them. Once a user needs to start paging through long lists of issues in a project, visual browsing becomes a very ineffective way to search and should not be the basis behind creating new projects.

In the examples above, we can see that equating a JIRA project with a business effort, or project, can work well… for a time. In the beginning (example 1) things ran smoothly for HealthFacts because there team was uniform and the project settings were simple, but when the company began to grow things became more complicated. They started experiencing problems with the system and began to find it difficult to find information. All of their problems could have been prevented with better organization
Every single project for the newsletter is identical to every other newsletter project except for the name and the tasks within. Every time a new project is created the same information and settings are copied from the older project. There is no need to have multiple projects when the setting of those projects is identical. Creating new projects, like in example 2, creates management overhead and could potentially create a security risk. Also, every time a new project is created it creates work for the administrators and creates the potential for an error to occur during the creation. If the newsletter team has used a single project for every newsletter they would not have an issue with the project settings as they did in example 2.
In example 3, the projects ended up impeding the user’s ability to find an issue rather than enhance it. The more projects there are, the more projects one must search through in order to research a past issue. Notice that Mary did not even use the project in her search criteria in example 3. If she had, they would not have been able to find the issue at all since it wasn’t in the project the assumed it would be in. Relying on the project could limit the scope of a user’s search, often times the project is not even utilized when searching.
It seems that the only real benefit of the numerous project method is it can make visual issue browsing more convenient. This is only true for very small projects. JIRA will only list 50 issues on a page; most projects will have more than 50 issues in them. Once a user needs to start paging through long lists of issues in a project, visual browsing becomes a very ineffective way to search and should not be the basis behind creating new projects.

Creativity

