Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Atlassian Cloud changes Nov 4 to Nov 11, 2019 | jimiwikman.se

    Atlassian Cloud changes Nov 4 to Nov 11, 2019

    Posted , 432 views, 0 comments ,

    This is a re-post of the Atlassian official documentation.

    Atlassian Cloud

    Your cloud-hosted products are supported by the Atlassian Cloud platform. This section usually includes changes related to multiple Atlassian Cloud products, site administration, and user management.

    Email users with suggested account changes

    ROLLING OUT

    From the Change details button, you can suggest that a user changes their account details to make their profile more consistent and easier to identify. Read more about administering Atlassian accounts.

     

    Give your users a Trusted permission

    ROLLING OUT

    From a user's Permission options, select Trusted to give certain users more responsibility. These users will be able to install and configure new products on your site and invite new users themselves.

     

    Claim accounts after verifying a domain

    ROLLING OUT

    To start managing accounts on your domain, we’ve included an additional step that requires you to claim accounts after verifying that you own the domain. From the table on the Domains page, click Claim accounts next to the verified domain. Read more about verifying a domain.

     

    Jira platform

    Changes in this section usually apply to all Jira products. We'll tell you in the change description if something is only for a specific Jira product.

    New user profile cards

    ROLLING OUT

    When you hover over someone’s name in directories, on dashboards, and in user picker fields, you’ll now start to see rich profile cards with more information and a link to the user’s profile (if you have permission to see it).

     

    New issue view: Rich user profile cards

    ROLLING OUT

    Get to know your team even faster. Our new user profile card provides more user information and a link to the user’s profile (if you have permission to see it). You’ll see it when you hover over someone’s name in user-picker fields (assignee, reporter, and other custom fields) and in issue activity feeds (comments, history, and the work log).

     

    Jira Software

    We're rolling out a new type of project known as next-gen. By default, any Jira Software licensed user can create their own next-gen project. These projects don't affect existing Jira projects, shared configurations, or your schemes. You can manage who's allowed to create next-gen projects with the new Create independent projects global permission. Read more about next-gen projects.

     

    New issue view for Jira Software

    ROLLING OUT

    Get a consistent view and edit experience with our new issue view for Jira Software. Click an issue to see its details, edit any field with a click, and add content with the quick-add buttons (under the issue summary). Take a look at the documentation for more info.

    We're adding new features and refining the design all the time, so click Give feedback on the issue view to let us know what you think.

     

    GitHub app on the Atlassian Marketplace

    ROLLING OUT

    We've partnered with GitHub to build a new and improved integration, which you can install at the Atlassian Marketplace. This replaces the DVCS connector in Jira's system settings. Current GitHub integrations set up under the old method will continue to work, but new integrations must be set up using the app on the Atlassian Marketplace. We're rolling out this update gradually, so it may not be on your Jira Cloud site yet.

    This won't affect GitHub Enterprise integrations, which must still be set up via the DVCS connector.

     

    Jira Service Desk

    Issues with the customer organizations field now use the organization name instead of ID when exporting to CSV

    ROLLING OUT NEW THIS WEEK

    When exporting Jira issues to CSV from the Jira Issue Navigator, the Custom field (Organizations) now contains the name of the organizations linked to the issue. The field previously contained the organization ID, which was not valuable for exports used for reporting.

    As part of this change, a CSV import can now match organizations by both their ID and their name. No changes are needed if you use CSV export files for import.

     

    Maintenance complete on the Request and Approvals pages

    ROLLING OUT NEW THIS WEEK

    We've completed some maintenance to the customer portal, you may notice some cosmetic updates to the Request and Approvals pages.

     

    New issue view for Jira Service Desk

    ROLLING OUT

    The new issue view groups key actions and information in a logical way, making it easier for you to scan and update requests. Learn more about the new issue view.

    Use keyboard shortcuts in your queues

     

    ROLLING OUT

    Use keyboard shortcuts to navigate around your queues and get your work done faster. You can now move through issues, select their fields, and go to the issue view from your queues just by using your keyboard!

     

    Customer portal request details page redesign

    ROLLING OUT

    We have redesigned the customer portal request details page to make it easier to use. You’ll notice we have added a rich text editor, sorted the activity stream from old to new, and have moved the location of the request fields, share button, approval and comment boxes.

     

    Easier configuration for the new issue view

    ROLLING OUT

    If you have the new issue view, you can now easily configure how your issue view looks for each request type.

    From your service desk project, go to Project settings > Request types and you'll find the new layout for making changes.

     

    Improved interface for your customer portal settings

    ROLLING OUT

    We’ve given the customer portal page in your project settings a visual overhaul. Settings are under suitable headings, text sizes are aligned, and overall, the page has a cleaner interface. Don’t worry, we haven’t removed any functionality.

    To see the new design in a classic project, go to Project settings > Portal settings.

    To see the new design in a next-gen project, go to Project settings > Channels > Customer portal.

     

    Confluence

    Portfolio for Jira plan macro

    ROLLING OUT NEW THIS WEEK

    The Portfolio for Jira plan Confluence macro lets you embed a Portfolio for Jira Server and Data Center plan in a Confluence page. Join key stakeholders in the spaces where business goals are built and tracked, and share how work is progressing across multiple projects and teams.

     

    Blogs are getting the first round of editing improvements

    ROLLING OUT

    If you've ever thought 'I wish it was easier to read blogs on mobile.... or on other devices', then this change is for you. Blogs are getting fixed-width layouts to improve readability across all devices. We're making a bunch of other updates to improve editing reliability and clean up your editing experience, so some macros may be temporarily unavailable while they're under maintenance. You can read more about these changes on our docs site.

     

    Teams have arrived in Confluence retrospectives!

    ROLLING OUT

    Instead of having to individually add each member of your team to a retrospective, Confluence now lets you assign people to Teams, so you can bulk add everyone at once.

    Use the retrospective template to see Teams in action. You can edit Teams through the retrospective-creation process, and add or edit other attendees for each retrospective you create.

     

    We're extending editing improvements to all pages on Android

    ROLLING OUT

    The editing improvements we made to blogs a few months ago are coming to the rest of your Android mobile pages, too. In addition to being faster and more reliable, your new pages are also responsive, optimized for readability, and have advanced tables. Some macros are still missing as we rebuild them, but you can check the list of changes and track updates to macros on our docs site.

     

    Confluence Cloud recent pages drawer

    ROLLING OUT

    We’ve made it easier to get to the pages you visited or worked with most recently. A new action has been added to the global sidebar that presents you with a list of your recent pages; interaction-specific tabs help you narrow the list based on your actions, like visited, edited, or saved as draft.

     

    Share pages directly with your team

    ROLLING OUT

    It’s now easier to share pages with everyone on your team, all in one go. When you click Share on any page or blog post, Confluence now lets you add a team – no need to enter each person individually. Learn more

     

    Bitbucket

    Retarget stacked Pull Requests

    ROLLING OUT NEW THIS WEEK

    Bitbucket will retarget the dependent pull requests to the branch that you're merging into, before closing the branch of the pull request you're merging. Previously, if there were dependent pull requests, you needed to update them manually with the new target branch. You will now see a checkbox with a link to the affected pull requests that will be retargeted.

    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Similar Content

    • By Jimi Wikman
      A walkthrough and guide on how to create and configure a board in Jira Software Cloud.
      0:00 - Intro 0:24 - What is a board? 01:27 - Two types of boards 02:10 - Jira without a board 02:41 - Create a board in Jira Software Cloud 04:50 - What is Roadmaps in Jira Software Cloud? 05:01 - What is a backlog in Jira Software Cloud? 06:02 - What is Active Sprints in Jira Software Cloud? 06:35 - General Boards Settings explained for Jira Software Cloud 08:52 - Column settings for Boards in Jira Software Cloud 09:02 - Column restraints for Boards in Jira Software Cloud 10:35 - Mange Columns in your Jira Software Cloud board 13:12 - Configure Swimlanes for your board in Jira Software Cloud 14:52 - Setup Quick filters for your board in Jira Software Cloud 17:22 - Card colors explained for your board in Jira Software Cloud 18:58 - Card layout explained for your board in Jira Software Cloud 21:23 - How to set up estimation for your board in Jira Software Cloud 23:08 - Working days for your board in Jira Software Cloud 23:57 - Issue Detail View explained for your board in Jira Software Cloud 25:17 - Configure Roadmaps for your board in Jira Software Cloud 26:22 - Outro
    • By Jimi Wikman
      In the previous article we discussed what tools we should use for what purpose. Now it's time to define the work we want to do in the different Areas of Responsibility. We do that by defining what different type of work we do in each so we can create a separate issue type for each type of work. This way we can separate work and can evolve the way we work in each through fields and workflows for example. Before we dig into that however we should first identify what issue types really are and how we should use them properly.
       
      The three levels of issues in Jira
      In Jira we have 3 levels of issue types. Each level is used for different purposes so it is important to understand what that purpose is so we can map our issue types to the right level.
      Epic - This is the highest level in Jira and it's purpose is to group and categorize the lower levels. In itself an Epic has no value and you can see it as a box or a rubber band that simply is used to group other items. The term epic means a story that extends over a long period of time or that it is something grand and impressive. This is also how it is meant to be used in Jira as a way to mark stories that are connected and span over two or more time periods.
        Standard Issue Type - This is the middle level in Jira and it's purpose if to act as the transitional item to indicate what responsibility area currently own the responsibility to do something. This type is the one that we design workflows for that are flow chart based and not in the form of state diagrams. We will cover this when going over workflows in a later article.
        Sub-Tasks - Within each responsibility area we have a need to break down the work so we can mark them as complete. These are referred to as producing items and unlike the Standard Issue Type we do not always use a tranistional workflow, but more of a task management flow of open, in progress, done .We will cover this when going over workflows in a later article. The majority of our issue types will fall into this category.
        Identifying the work that need to be done
      With the issue types identified we can now begin to define what issue types we need for our setup. We previously identified Requirement, Development, Test and Acceptance as our areas that use Confluence and Jira, so we will break down the work in those areas and see what we can come up with.
      Requirement
      Requirement: Standard Issue Type (optional) - If we want, we can use a separate issue type to act as the object which we work through the requirement process. This should be done in a separate project as it will contain a large number of unprocessed need. This would make managing the development projects less efficient, but we will discuss that in another article.
        Story: Standard Issue Type - This is the output from the Requirement process and while the name might make you think it comes from the fact that many requirements are written in the form or user stories. This is not accurate however as requirements can come in many forms and shapes. Story refer to the fact that we get the need explained to us as a story, which is because as humans we communicate in the form of stories.
        Design: Standard Issue Type & Sub-task - Design (UX/UI) can be done separate, which is why we have a Standard Issue Type for it. It can also be done as part of a requirement which is why we have a sub-task for it as well. In some cases we need to make adjustments in existing requirements and there we also use a sub-task connected to a Story for that purpose.
        Technical Design: Standard Issue Type & Sub-task - Just like with Design we have both a standard issue type and a sub-task.
        Technical Debt: Standard Issue Type - This is a rare issue type in many companies, but it is used when decisions are made that create technical debt or when clean up need to be done to optimize systems and data. These are IT driven stories in nature with the intent to make sure IT driven concerns are logged and prioritized alongside business need. It is also used to highlight decisions that will have a cost in the future. Development
      Development: Sub-Task - It may seem strange that Development only exist as sub-task, but the reason for that is that development only happen when there is a need for it. This need is in the form of a Story or Technical debt. That is why development only exist as a sub-task and it is used for writing code.
        Build & Configure: Sub-task - Again this is only available as a sub-task for the same reason as for Development. This issue type is used when there is no code related to the task, just configuration. It is also used to build systems such as servers that are again configurations or physical assembly tasks. Common tasks are upgrades or adding new subset of a system through configuration.
        Defect: Standard Issue Type & Sub-task - The default way to create defects is as sub-tasks connected to a story. This block the story from deployment as it can never be closed with open sub-tasks. The standard issue type is used when defects are found without direct connection to a development or when you want to break out a defect as a known defect, but still close the story for deploy. Defect can only happen before code is put into production. I usually rename the standard Bug issue type to Defect if possible, otherwise I create a new issue type for it.
        Incident: Standard Issue Type - Incident is used for defects that are found after the code is put into production. It is separate from defect in order to properly identify where a defect has been discovered as that can affect legal aspects. It is also used to allow proper focus and prioritization as production defects usually need high attention. All incidents are standard issue types as the stories they comes from have already been closed.
        Feature Toggle: Sub-Task (optional) - This is a bit of an odd addition lately and it act as a way to determine what code is in what code based, even if it is not activated. We will not dig to much into this one as it's an article in itself. It is just added in case you work with feature toggle in your project. Test & Acceptance
      Test / Acceptance: Standard Issue Type & Sub-task (optional) - This is again an optional issue type due to the fact that most test add-ons have the functionality needed to keep track of time and effort. In the event that you need a way to add time and effort outside the add-on, then you can create an issue type for this as placeholder for that information. Generic
      Epic: Epic - This is standard in Jira and it is used, as described above, to group standard issue types.
        Task: Standard Issue Type & Sub-task - Tasks and Sub-tasks are standard in Jira and they can be used for any task not defined in other issue types. This can be things like scheduling meetings, organize workshop or buy cake for the team.  
      Color coding for visual guidance
      In order to make it even easier to identify what the different issue types will be used for I always create custom icons and color code them. This visualize the area of responsibility as well as the purpose of the issue types. My way to color code is based on color theories and my own preferences, so feel free to adjust if needed.
      Requirements - This is an interpretation of the business need to Development. I tend to color Business in blue/teal as corporate colors and Development as red. The combination of those two is purple, so I make the Issue types related to Requirements as purple.
        Development - This is the heart of the work flow. We tend to want incidents and defects highly visible as well, so we pick the color that match those requirements. We tie this into the traffic sign colors used in test and acceptance as well. This is why everything related to development is red.
        Test - This is where code is either allowed to pass to acceptance, or pushed back to development for further adjustment. It is something we want to make sure it has good attention and we also follow the traffic sign color schemes used in development and acceptance. this is why test is yellow, sometimes with a orange tint to tie it closer to development.
        Acceptance - This is where a need is given the thumbs up or the big GO. We use the traffic sign color scheme to signal this and for that reason Acceptance is green. I use icons that I feel is matching the issue type itself to further clarify purpose. I also use en inverted design to distinguish between standard issue types and sub-tasks. You can see some of the icons in the download section. You are free to use the icons in your Jira instance as they are created by me using the free version of fontawesome.
       
      Setting up Issue Types in Jira
      Now that we have defined the issue types and designed the icons it's time to set this up in Jira. I will set this up in my Demo Jira which is cloud based. If you use Server or Data Center version the way you set this up will look a little different, but the functionality will be the same.
      In order to get the new issue types into our project we will need to do three things:
      Create the new Issue Types Create a new Issue Type Schema and add the Issue Types to that Schema Assign the Issue Type Schema to our project.  
      Create Issue Types
      In Jira Cloud we do this under Jira Settings -> Issues -> Issue Types. Please note that you need admin access for this step. Here you will see a list of the current Issue Types and in the top right corner you will have a button that say "Add issue type". Clicking on that will give you a popup where you can create a new issue type.
       
      Once you add the name and description of the new issue type, then you select what type of issue type you want it to be. You can not add an image at the time I am writing this, so you will get a generic icon for it when you click add. Once created you simply find it in the list and click edit to change the icon by uploading a new one.
      Next to the icon click "Select Image" and then "upload avatar" in the popup. Select a new image, close the poup and then click on update to save the new image.
       
       
      Create a new Issue Type Schema
      Under Jira Settings -> Issues -> Issue Type Schemes you find a list of the different issue type schemes you currently have in your Jira. In the top right corner you find a button with the text "Add Issue Type Scheme". Click that to create a new scheme. Please note that you need admin access for this step.
      When you create the scheme you add a name for the scheme, a description and then you drag the issue types you want to add to the scheme from the list on the right to the list on the left. Once you have done that you can select "Story" as the default issue type. This will make Story the pre-selected issue type when we click on Create in a project using this Scheme. Once done, click save.
       
       
      Add Issue Type Scheme to your project
      Go to your project and then click on project setting in the left menu. It should be at the bottom of the list of areas for your project, but if you can not see it then you may not have admin rights for your project and you need to get some help with this step. If you have access then in the project settings go to Issue Types.
      This view will show you the current issue type scheme and the issues included in that scheme. In the top right corner you will see a drop list with a cog wheel that say "Actions". Clicking this will allow you to edit the issues in the scheme, but we want the other function called "Use a different scheme".
       
       
      Simply select the Issue Type Scheme created earlier by first making sure you select "Choose an existing issue type scheme" and then the correct issue type scheme in the list below. Click OK and your project will now be associated with the new issue type scheme we created and with that we now have our new issue types.
       
       
      We now have the proper issue types we need to work, but in order for them to really useful we need to make sure we have workflows that match the work we do. This is what we will focus on in our next article: Setup Jira & Confluence for success - Part 3: Defining Jira Issue workflows.
    • By Jimi Wikman
      In the previous article we discussed what tools we should use for what purpose. Now it's time to define the work we want to do in the different Areas of Responsibility. We do that by defining what different type of work we do in each so we can create a separate issue type for each type of work. This way we can separate work and can evolve the way we work in each through fields and workflows for example. Before we dig into that however we should first identify what issue types really are and how we should use them properly.
       
      The three levels of issues in Jira
      In Jira we have 3 levels of issue types. Each level is used for different purposes so it is important to understand what that purpose is so we can map our issue types to the right level.
      Epic - This is the highest level in Jira and it's purpose is to group and categorize the lower levels. In itself an Epic has no value and you can see it as a box or a rubber band that simply is used to group other items. The term epic means a story that extends over a long period of time or that it is something grand and impressive. This is also how it is meant to be used in Jira as a way to mark stories that are connected and span over two or more time periods.
        Standard Issue Type - This is the middle level in Jira and it's purpose if to act as the transitional item to indicate what responsibility area currently own the responsibility to do something. This type is the one that we design workflows for that are flow chart based and not in the form of state diagrams. We will cover this when going over workflows in a later article.
        Sub-Tasks - Within each responsibility area we have a need to break down the work so we can mark them as complete. These are referred to as producing items and unlike the Standard Issue Type we do not always use a tranistional workflow, but more of a task management flow of open, in progress, done .We will cover this when going over workflows in a later article. The majority of our issue types will fall into this category.
        Identifying the work that need to be done
      With the issue types identified we can now begin to define what issue types we need for our setup. We previously identified Requirement, Development, Test and Acceptance as our areas that use Confluence and Jira, so we will break down the work in those areas and see what we can come up with.
      Requirement
      Requirement: Standard Issue Type (optional) - If we want, we can use a separate issue type to act as the object which we work through the requirement process. This should be done in a separate project as it will contain a large number of unprocessed need. This would make managing the development projects less efficient, but we will discuss that in another article.
        Story: Standard Issue Type - This is the output from the Requirement process and while the name might make you think it comes from the fact that many requirements are written in the form or user stories. This is not accurate however as requirements can come in many forms and shapes. Story refer to the fact that we get the need explained to us as a story, which is because as humans we communicate in the form of stories.
        Design: Standard Issue Type & Sub-task - Design (UX/UI) can be done separate, which is why we have a Standard Issue Type for it. It can also be done as part of a requirement which is why we have a sub-task for it as well. In some cases we need to make adjustments in existing requirements and there we also use a sub-task connected to a Story for that purpose.
        Technical Design: Standard Issue Type & Sub-task - Just like with Design we have both a standard issue type and a sub-task.
        Technical Debt: Standard Issue Type - This is a rare issue type in many companies, but it is used when decisions are made that create technical debt or when clean up need to be done to optimize systems and data. These are IT driven stories in nature with the intent to make sure IT driven concerns are logged and prioritized alongside business need. It is also used to highlight decisions that will have a cost in the future. Development
      Development: Sub-Task - It may seem strange that Development only exist as sub-task, but the reason for that is that development only happen when there is a need for it. This need is in the form of a Story or Technical debt. That is why development only exist as a sub-task and it is used for writing code.
        Build & Configure: Sub-task - Again this is only available as a sub-task for the same reason as for Development. This issue type is used when there is no code related to the task, just configuration. It is also used to build systems such as servers that are again configurations or physical assembly tasks. Common tasks are upgrades or adding new subset of a system through configuration.
        Defect: Standard Issue Type & Sub-task - The default way to create defects is as sub-tasks connected to a story. This block the story from deployment as it can never be closed with open sub-tasks. The standard issue type is used when defects are found without direct connection to a development or when you want to break out a defect as a known defect, but still close the story for deploy. Defect can only happen before code is put into production. I usually rename the standard Bug issue type to Defect if possible, otherwise I create a new issue type for it.
        Incident: Standard Issue Type - Incident is used for defects that are found after the code is put into production. It is separate from defect in order to properly identify where a defect has been discovered as that can affect legal aspects. It is also used to allow proper focus and prioritization as production defects usually need high attention. All incidents are standard issue types as the stories they comes from have already been closed.
        Feature Toggle: Sub-Task (optional) - This is a bit of an odd addition lately and it act as a way to determine what code is in what code based, even if it is not activated. We will not dig to much into this one as it's an article in itself. It is just added in case you work with feature toggle in your project. Test & Acceptance
      Test / Acceptance: Standard Issue Type & Sub-task (optional) - This is again an optional issue type due to the fact that most test add-ons have the functionality needed to keep track of time and effort. In the event that you need a way to add time and effort outside the add-on, then you can create an issue type for this as placeholder for that information. Generic
      Epic: Epic - This is standard in Jira and it is used, as described above, to group standard issue types.
        Task: Standard Issue Type & Sub-task - Tasks and Sub-tasks are standard in Jira and they can be used for any task not defined in other issue types. This can be things like scheduling meetings, organize workshop or buy cake for the team.  
      Color coding for visual guidance
      In order to make it even easier to identify what the different issue types will be used for I always create custom icons and color code them. This visualize the area of responsibility as well as the purpose of the issue types. My way to color code is based on color theories and my own preferences, so feel free to adjust if needed.
      Requirements - This is an interpretation of the business need to Development. I tend to color Business in blue/teal as corporate colors and Development as red. The combination of those two is purple, so I make the Issue types related to Requirements as purple.
        Development - This is the heart of the work flow. We tend to want incidents and defects highly visible as well, so we pick the color that match those requirements. We tie this into the traffic sign colors used in test and acceptance as well. This is why everything related to development is red.
        Test - This is where code is either allowed to pass to acceptance, or pushed back to development for further adjustment. It is something we want to make sure it has good attention and we also follow the traffic sign color schemes used in development and acceptance. this is why test is yellow, sometimes with a orange tint to tie it closer to development.
        Acceptance - This is where a need is given the thumbs up or the big GO. We use the traffic sign color scheme to signal this and for that reason Acceptance is green. I use icons that I feel is matching the issue type itself to further clarify purpose. I also use en inverted design to distinguish between standard issue types and sub-tasks. You can see some of the icons in the download section. You are free to use the icons in your Jira instance as they are created by me using the free version of fontawesome.
       
      Setting up Issue Types in Jira
      Now that we have defined the issue types and designed the icons it's time to set this up in Jira. I will set this up in my Demo Jira which is cloud based. If you use Server or Data Center version the way you set this up will look a little different, but the functionality will be the same.
      In order to get the new issue types into our project we will need to do three things:
      Create the new Issue Types Create a new Issue Type Schema and add the Issue Types to that Schema Assign the Issue Type Schema to our project.  
      Create Issue Types
      In Jira Cloud we do this under Jira Settings -> Issues -> Issue Types. Please note that you need admin access for this step. Here you will see a list of the current Issue Types and in the top right corner you will have a button that say "Add issue type". Clicking on that will give you a popup where you can create a new issue type.
       
      Once you add the name and description of the new issue type, then you select what type of issue type you want it to be. You can not add an image at the time I am writing this, so you will get a generic icon for it when you click add. Once created you simply find it in the list and click edit to change the icon by uploading a new one.
      Next to the icon click "Select Image" and then "upload avatar" in the popup. Select a new image, close the poup and then click on update to save the new image.
       
       
      Create a new Issue Type Schema
      Under Jira Settings -> Issues -> Issue Type Schemes you find a list of the different issue type schemes you currently have in your Jira. In the top right corner you find a button with the text "Add Issue Type Scheme". Click that to create a new scheme. Please note that you need admin access for this step.
      When you create the scheme you add a name for the scheme, a description and then you drag the issue types you want to add to the scheme from the list on the right to the list on the left. Once you have done that you can select "Story" as the default issue type. This will make Story the pre-selected issue type when we click on Create in a project using this Scheme. Once done, click save.
       
       
      Add Issue Type Scheme to your project
      Go to your project and then click on project setting in the left menu. It should be at the bottom of the list of areas for your project, but if you can not see it then you may not have admin rights for your project and you need to get some help with this step. If you have access then in the project settings go to Issue Types.
      This view will show you the current issue type scheme and the issues included in that scheme. In the top right corner you will see a drop list with a cog wheel that say "Actions". Clicking this will allow you to edit the issues in the scheme, but we want the other function called "Use a different scheme".
       
       
      Simply select the Issue Type Scheme created earlier by first making sure you select "Choose an existing issue type scheme" and then the correct issue type scheme in the list below. Click OK and your project will now be associated with the new issue type scheme we created and with that we now have our new issue types.
       
       
      We now have the proper issue types we need to work, but in order for them to really useful we need to make sure we have workflows that match the work we do. This is what we will focus on in our next article: Setup Jira & Confluence for success - Part 3: Defining Jira Issue workflows.

      View full blog article
    • By Jimi Wikman
      The first thing we need to do before we can actually build the setup in Jira and Confluence is to define the tools. What should be done in what tool. We also need to define how we will use the tools based on what need we have. This may sound easy, but it is actually a bit trickier than it sounds and it's the source of many failures when using Jira especially.
       
      Who are we building for?
      In our example, we will build a setup based on a development team. It is a traditional team that tries to adopt some agile methodologies. The company is medium-sized with dozens of teams distributed in several countries where waterfall methodologies are still the norm. Most development happen in projects, which cause some overlap, but overall this get done even if it is not always easy. Requirements have decent quality, but varies greatly between teams, and most work process related changes are driven by management and test.
      In short, it is a pretty common situation for many companies. There are some challenges, but the organization is moving towards a more agile and uniform way of working. There is a struggle over control and visibility because the teams want more freedom and the managers still want to feel that they have the control because they are still a bit too far away from the teams.
       
      The Areas of Responsibility
      In order to see what tool is best suited for what task, then we need to identify who do what. We start this by breaking down areas of responsibility so we know what areas we hand over responsibility to. In our setup, we identify the following areas:
      Business - This is where the need originates from. This is actually a whole process in itself, but we just consider the output as a responsibility area. This is represented by the Product Owner. Requirement - This is where the need is defined and translated to actionable information for the development team. We include design (UI/UX), technical design and non-functional requirements such as legal as part of this area as well. This is because they are supporting the requirement process. Development - This is where the need is realized in the form of code. Test - This is where we ensure the development have good quality. Acceptance - This is where business ensure that the need has been fulfilled. Doing so also conclude the legal agreement between business and development. Deployment - This is where the need is made available to the end users. Support - This is where feedback related to the need is managed. Since we are building in Jira and Confluence, all of these areas are not going to be represented due to the limitations and capabilities in those tools. In order to identify the best tool for the job, we identify the need for each area.
      Business - Jira Align
      This is a big area that are actually made up of multiple processes. In this area we need to be able to organize people, money and resources into initiatives that span the whole company. We need to follow up and see when cross initiatives have issues in order to mitigate. This area do not just deal with IT, but include things like marketing, product development, human resources and so on. Jira and Confluence are not a good match for this area. Instead, portfolio tools such as Jira Align or Portfolio for Jira are better choices.
      Requirement - Confluence
      This area work with documentation to break down a need into actionable items. Design is delivered in multiple versions and file formats. Technical design include flow charts and tabled specification of data. Legal and non-functional requirements are usually global, so we need to be able to link in from other locations. We also want to prioritize work, add estimations on multiple levels and eventually create work orders that can be traced back to the original need. Since a requirement is both a translation of a need to an actionable task and a legal agreement on what need to be done, we need to be able to control the requirement. This means that we need both version control to identify changes and the possibility to restrict editing when agreed upon. We will use Confluence for this area for the final documentation. We will also use Jira as an optional tool to drive the requirement forward until it is ready to be locked down in Confluence.
      Development - Jira Software
      This area work with code where they need to have tasks on what to do. This task is actually the work order, and as such it must be connected all the way to the need. This area also need to connect the work with the code in order to trace work to code packages. We need the ability to assign work, so someone is responsible to fulfill the need. We want to see what is ready to be worked on and if the code package is ready to be deployed. This means that we need to be able to see other areas as well in a workflow. For this purpose we use Jira and connect to the requirements in Confluence. The Development team will also use Bitbucket to manage their code.
      Test - Jira Add-On
      This area work with making sure that the code we produce are in accordance with the requirement and that it has good quality. We need to be able to create test cases for what to test and then a way to connect to series of test. These must be reusable so we can use them to make the same tests multiple times. We need a good way to report when something is not working so we can bring that back to the development team to be fixed. We need a way to get reports on progress and result of the tests. Jira and Confluence does not support this fully, so we will add an Add-On for this to extend that capability and connect it to the development tasks.
      Acceptance - Jira Add-On
      This area work with making sure that the need is fulfilled. It is testing in the same manner that the test area, but on a different level and with a different responsible group. We will use the same setup as for Test with the same Jira Add-On, but connect to the requirements instead of the development tasks.
      Deployment - Bitbucket Pipelines / Bamboo
      This area work with making sure that the code packages created by Development are moved to the different environments. In order to do this they need a way to deliver code between the environments. This in not something that we can do in Jira or Confluence. Instead, a tool like Bamboo or Bitbucket Pipelines will be used. We will however use the Release feature in Jira to connect the code base with the deploys for traceability. We will also use Confluence to document deployments to production for traceability.
      Support - Jira Service Management
      This area work with supporting the code that is available in production. This requires the ability to manage incoming support requests, identifying resolutions and when needed to create work tasks for different teams. Continuous communication with the reporter is a must, and there should also be a way to resolve repeating requests to reduce duplicated requests. For this Jira and Confluence is not fully what we need. Jira Service Management is a better option for this.
       
      As we can see from this our setup for Confluence and Jira will support Requirement, Development, Test and Acceptance. We will connect with Deployment as well, but the full capability will not be in our setup. Now that we know what we are going to support, then it is time to start looking at what work we actually do in each area so we can define the issue types.
      This we will go over in our next article:  Setup Jira and Confluence for success - Part 2: Defining Jira Issue Types
       
    • By Jimi Wikman
      The first thing we need to do before we can actually build the setup in Jira and Confluence is to define the tools. What should be done in what tool. We also need to define how we will use the tools based on what need we have. This may sound easy, but it is actually a bit trickier than it sounds and it's the source of many failures when using Jira especially.
       
      Who are we building for?
      In our example, we will build a setup based on a development team. It is a traditional team that tries to adopt some agile methodologies. The company is medium-sized with dozens of teams distributed in several countries where waterfall methodologies are still the norm. Most development happen in projects, which cause some overlap, but overall this get done even if it is not always easy. Requirements have decent quality, but varies greatly between teams, and most work process related changes are driven by management and test.
      In short, it is a pretty common situation for many companies. There are some challenges, but the organization is moving towards a more agile and uniform way of working. There is a struggle over control and visibility because the teams want more freedom and the managers still want to feel that they have the control because they are still a bit too far away from the teams.
       
      The Areas of Responsibility
      In order to see what tool is best suited for what task, then we need to identify who do what. We start this by breaking down areas of responsibility so we know what areas we hand over responsibility to. In our setup, we identify the following areas:
      Business - This is where the need originates from. This is actually a whole process in itself, but we just consider the output as a responsibility area. This is represented by the Product Owner. Requirement - This is where the need is defined and translated to actionable information for the development team. We include design (UI/UX), technical design and non-functional requirements such as legal as part of this area as well. This is because they are supporting the requirement process. Development - This is where the need is realized in the form of code. Test - This is where we ensure the development have good quality. Acceptance - This is where business ensure that the need has been fulfilled. Doing so also conclude the legal agreement between business and development. Deployment - This is where the need is made available to the end users. Support - This is where feedback related to the need is managed. Since we are building in Jira and Confluence, all of these areas are not going to be represented due to the limitations and capabilities in those tools. In order to identify the best tool for the job, we identify the need for each area.
      Business - Jira Align
      This is a big area that are actually made up of multiple processes. In this area we need to be able to organize people, money and resources into initiatives that span the whole company. We need to follow up and see when cross initiatives have issues in order to mitigate. This area do not just deal with IT, but include things like marketing, product development, human resources and so on. Jira and Confluence are not a good match for this area. Instead, portfolio tools such as Jira Align or Portfolio for Jira are better choices.
      Requirement - Confluence
      This area work with documentation to break down a need into actionable items. Design is delivered in multiple versions and file formats. Technical design include flow charts and tabled specification of data. Legal and non-functional requirements are usually global, so we need to be able to link in from other locations. We also want to prioritize work, add estimations on multiple levels and eventually create work orders that can be traced back to the original need. Since a requirement is both a translation of a need to an actionable task and a legal agreement on what need to be done, we need to be able to control the requirement. This means that we need both version control to identify changes and the possibility to restrict editing when agreed upon. We will use Confluence for this area for the final documentation. We will also use Jira as an optional tool to drive the requirement forward until it is ready to be locked down in Confluence.
      Development - Jira Software
      This area work with code where they need to have tasks on what to do. This task is actually the work order, and as such it must be connected all the way to the need. This area also need to connect the work with the code in order to trace work to code packages. We need the ability to assign work, so someone is responsible to fulfill the need. We want to see what is ready to be worked on and if the code package is ready to be deployed. This means that we need to be able to see other areas as well in a workflow. For this purpose we use Jira and connect to the requirements in Confluence. The Development team will also use Bitbucket to manage their code.
      Test - Jira Add-On
      This area work with making sure that the code we produce are in accordance with the requirement and that it has good quality. We need to be able to create test cases for what to test and then a way to connect to series of test. These must be reusable so we can use them to make the same tests multiple times. We need a good way to report when something is not working so we can bring that back to the development team to be fixed. We need a way to get reports on progress and result of the tests. Jira and Confluence does not support this fully, so we will add an Add-On for this to extend that capability and connect it to the development tasks.
      Acceptance - Jira Add-On
      This area work with making sure that the need is fulfilled. It is testing in the same manner that the test area, but on a different level and with a different responsible group. We will use the same setup as for Test with the same Jira Add-On, but connect to the requirements instead of the development tasks.
      Deployment - Bitbucket Pipelines / Bamboo
      This area work with making sure that the code packages created by Development are moved to the different environments. In order to do this they need a way to deliver code between the environments. This in not something that we can do in Jira or Confluence. Instead, a tool like Bamboo or Bitbucket Pipelines will be used. We will however use the Release feature in Jira to connect the code base with the deploys for traceability. We will also use Confluence to document deployments to production for traceability.
      Support - Jira Service Management
      This area work with supporting the code that is available in production. This requires the ability to manage incoming support requests, identifying resolutions and when needed to create work tasks for different teams. Continuous communication with the reporter is a must, and there should also be a way to resolve repeating requests to reduce duplicated requests. For this Jira and Confluence is not fully what we need. Jira Service Management is a better option for this.
       
      As we can see from this our setup for Confluence and Jira will support Requirement, Development, Test and Acceptance. We will connect with Deployment as well, but the full capability will not be in our setup. Now that we know what we are going to support, then it is time to start looking at what work we actually do in each area so we can define the issue types.
      This we will go over in our next article:  Setup Jira and Confluence for success - Part 2: Defining Jira Issue Types
       

      View full blog article
×
×
  • Create New...