Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'jira'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Organization
  • Leadership
  • Requirements
  • Design
    • User Experience
    • User Interface
  • Development
    • Frontend
  • Quality & Security
  • Deployment & Network
  • Atlassian
    • Jira
    • Confluence
    • Bitbucket
  • Wordpress
  • E-commerce

Categories

  • School
  • Certification
  • Courses

Categories

  • Project Manager
  • Process & Method Specialist

Categories

  • Records

Categories

  • Leadership

Categories

  • Bugtracker

Product Groups

  • Demo product

Calendars

  • Community Calendar
  • Organization Events
  • Leadership Events
  • Design Events
  • Development Events
  • Deployments Events
  • Requirement Events
  • Quality Events
  • Atlassian Events
  • Wordpress Events
  • Atlassian AUG Stockholm's Events

Forums

  • General Area
    • General Area
  • Areas of interest
    • Organization
    • Leadership
    • Design
    • Development
    • Deployment
    • Requirements
    • Quality
  • Special Areas
    • Atlassian
    • Wordpress
  • Atlassian AUG Stockholm's Diskussioner

Blogs

There are no results to display.

There are no results to display.

Categories

  • Files
  • Fonts
  • Atlassian AUG Stockholm's Filer

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 5 results

  1. The question of using groups or roles in Jira is always active and you have people advocating both passionately. In my experience Roles is the preferred way to secure your jira instance when you are working in larger companies where user management is not handled in Jira itself. Groups is an excellent way to quickly manage users. It requires one activity and can add a user to multiple projects in one swift action. The downside is that if you do not have control of the group itself, then it quickly becomes a black hole in your solution. This is a common issue in large organizations where the management of the groups are done outside of Jira, for example in an AD. The separation from Jira, both for the creation of groups and the approval of adding users to a group, makes it impossible for the project owner in Jira to know who is actually in a group. On the other hand the approver on the other side know what users are in the group, but not what projects in Jira they have access to. If you also add the common issue with on boarding and off boarding users that often is handled by a central support organization, then you might have a problem keeping track of who actually have access to what information in Jira. As I am a strong advocate of the shift-left way of working I often suggest moving to a roles based setup. This forces the Jira Project Admins to take responsibility for adding and removing users to their project. It also remove the need for support to manage the users, which speed up the process of adding and removing users AND it naturally break down larger projects to smaller ones. This is often beneficial as many larger organization has this fear that having many projects make it difficult to work across Jira projects. This creates mega projects with hundreds of teams, which is not very efficient or fun to work in. Splitting into smaller projects also clarify where there are missing roles, which is not always clear in mega projects. When I create my roles I try to break them down into two types: Access and logical units. Access of course dictate what actions you can take within a project and I tend to have just three roles as I think you should trust the members of your project. The roles I define are Admins, users and watchers. Admins are of course the people that can do the bulk changes and manage the projects. Users are the ones that do the actual work and watchers are people that want access to see what is going on. The users I then break down into logical units. Not for access or permissions, but to visualize what people are actually in the project. Depending on the type of project these roles can be a bit different. If it is a development project I would add these roles: Management - Management people involved in the project. Typically business owners and stakeholders on the business side and project managers on the development side. Requirement - For the people working with requirement. Designing - UI/UX designers. Development - The developers and architects. Testing - Test lead, manual testers and developers of automated tests. Acceptance - The people in charge of accepting the solution through acceptance testing. Deployment - If it is applicable and there are specific deployment managers. Doing this break down illustrate pretty clearly if the project is people in key roles. If you have 100 developers and 3 testers, then you are most likely not optimized for quality deliveries. The same thing if you have people that complain that they are both management and acceptance, then you know you are missing technical acceptance testers. I know some companies separate internal development from external sourcing partners. This is not very good to do because it creates a gap in the information flow and if you have selected someone as your sourcing partner, then you should be able to trust them. If you have information that they should not be aware of, then make sure you separate that in a different project, not using roles or groups within the same project. It quickly becomes messy and people are uncomfortable hiding things from each other. I know there are challenges with breaking up larger projects to smaller ones, especially when working with tests, but that is a topic for next time. Until then, do you agree with my thoughts on groups vs roles for Jira?
  2. Invision is a popular tool for visual designers and UX designers, but it is usually a pain to transfer the information over to Jira. With Invision for Jira that becomes less problematic since you can embed an inline prototype directly into a Jira issue that also include the inspect function that makes life easier for the developers. While this is very nice, it really is just a fancy way to link people to Invision because the links will take you to Invision and you get the same issue with making sure everyone have a login and understand the way Invision works. This does not solve the actual problem to bring in the information the designers need into the documentation, it just add a more convenient way to direct the users to Invision. So this leaves the designs in Invision, which is not a good place to keep designs once they are agreed upon since you need to ensure the designs are not continuously improved as that cause issues with requirements. This can be solved by transferring projects to a another, controlled Invision instance, but that is messy and prone to confusion and mistakes. What I would like to have is a way to embed this directly into Confluence where it can be version handled and controlled from a requirements perspective. The concept is amazing, but the solution right now is not enough for a good way to bring in design in a controlled way as a requirement into Jira unfortunately.
  3. Gliffy Projects for Jira is another great product from the Gliffy Team and this time they help bridging the gap between design and development. It's an easy concept that is easily understood by the designers using hotspots in the design directly connected to development tasks. The concept is super easy and it is quite nice to be able to just add work tasks directly to a design the way Gliffy Projects do it. The down side however is that you need to use another image manager which is the Gliffy Projects. If I am already using Invision for example it does not really feel natural to add the images again to another tool just to create the hotspots to Jira. For this to be a slam dunk I would love to see it integrated in Confluence like their other products so I can stay in one tool for requirements and from there simply connect the uploaded designs in the same way. I do hope Gliffy are working on this because that would make this an invaluable tool in any project using visual design or workflows that need to be translated into activities.
  4. Announcements in Jira is an important part of the Jira administrators job. The balance between being annoying and not keeping the users properly informed is a thin line indeed. While Jira provide email and banner options, its still a blunt tool to use and sometimes you even wish for your Jira Project Leaders to have the power to keep their projects informed. This is where Announcer for Jira can help. With it's flexible system it can inform users in many ways, including group selection, scheduled notifications, several types of notifications and more you can make your notifications as unobtrusive as your users need them to be. It's quite the tool to add to your arsenal of plugins and during upgrades and incidents your users will love you for giving them the power to be informed.
  5. One common question that often comes up is what the difference is between especially business projects and Software projects. In Jira Software this is not very clear and as a result I see almost all projects are created as Software projects. Lets go through the differences to see what a project type is and how it can be used in your project. In Jira there are three different project types that you can have: Business project - Jira Core. Software Project - Jira Software Jira Service Desk Project - Jira Service Desk The different project types comes with some specific features. This means that based on the project types you will see a different set of functionality in your project. These are referred to as Application Specific Features. In essence the choice between the different project types define a template that decides what the project you create will have in terms of functionality. If you accidentally choose the wrong type, then you can always change that later and the new choice will again create the functionalities related to the template. Business Project If you choose Business Project, then you will get the default functions that are included in Jira Core. This project type is best suited for projects that work a lot with tasks. Software Project If you choose Software Project, then you will get the default functions that are included in Jira Core plus the functionalities to work with Agile Boards, Integration with development tools and release hubs for software version release. This is the recommended project type if you work in an Agile way and need the scrum board, or if you work with development so you need the release information or integrate with development tools. Jira Service Desk Project This add the service desk functionality such as SLA's and the Que view. It also add some specific Service Desk gadgets. This project type is useful for projects where SLA's are very important and in projects where you need a specific flow for support. Unlike the Business Project and the Software project this project type can feel very different as the view is arranged in a different way to better fit the need of a service desk staff. A Summary of the Project Types Project Types are NOT the same as Project Templates It is very important to understand that Project types are not the same as project templates. Project types define the underlying functionality of the project while templates change the layout and interaction with the project. We will cover the template types in a different blog post if you think that could be interesting. If you want to read more about project types, feel free to read the Atlassian documentation here.
here
×