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

Search the Community

Showing results for tags 'jira'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Management
  • Design
  • Requirements
  • Development
  • Test
  • Atlassian

Categories

  • Personal
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-Commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-Commerce
  • Others

Categories

  • Thoughts
  • Debate
  • Health
  • Hobbies

Categories

  • Personligt
    • Åsikter
    • Humor
    • Spel
    • Träning
  • Allmänt
    • Internet
    • Program & tjänster
  • Intressant
    • Prylar
  • Professionellt
    • Management
    • Krav
    • Designs
    • Webbutveckling
    • Test
    • Atlassian
    • säkerhet
    • Förvaltning
    • Ehandel
    • Wordpress
  • Personligt_

Categories

  • Prologue
    • About This Book
  • The Tools
    • Jira Software
    • Confluence
    • Jira Service Management
  • The Inception Phase
    • Portfolio Management
    • Project Management
  • The Design Phase
    • Design as part of the Inception phase
    • Design as part of the Requirement phase
    • Working with design libraries
  • The Requirement Phase
    • Definition of Requirements
    • The four levels of Requirements
  • The Development Phase
    • Atomic design
    • Estimations
  • The Test Phase
    • The Definition of Test
    • Types of Test
  • The Operations Phase
    • Release Management
  • The Post Go-Live Phase
    • Incidents
    • Changes
  • Notes
    • My Muses
    • Research

Categories

  • Theme Building
  • Javascript Framework
  • CSS Framework
  • IPS: Pages
    • Database Templates
    • Block Plugin Templates
    • Page Templates
  • Custom Applications
  • Tips & Tricks

Categories

  • Europe
    • Central Europe
    • Eastern Europe
    • Northern Europe
    • Southeastern Europe
    • Southern Europe
    • Western Europe
  • North America
    • United States of America
    • Canada
    • Mexico
    • Caribbean
    • Central America
  • South America
    • Argentina
    • Bolivia
    • Brazil
    • Chile
    • Colombia
    • Ecuador
    • Falkland Islands
    • Guyana
    • Paraguay
    • Peru
    • Suriname
    • Uruguay
    • Venezuela
  • Africa
    • Northern Africa
    • Central Africa
    • Western Africa
    • Eastern Africa
    • Southern Africa
  • Asia
    • Central Asia
    • East Asia
    • South-Eastern Asia
    • Southern Asia
    • Western Asia
  • Oceania
    • Australia
    • Fiji
    • Kiribati
    • Marshall Islands
    • Micronesia
    • Nauru
    • New Zealand
    • Palau
    • Papua New Guinea
    • Samoa
    • Solomon Islands
    • Tonga
    • Tuvalu
    • Vanuatu

Categories

  • Shared Hosting
  • Virtual Private Server
  • Cloud Hosting
  • Dedicated Hosting
  • Co-Location
  • Hosting Services

Categories

  • Records

Categories

  • Professional
    • Management
    • Design
    • Requirements
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Categories

  • Requirements

Categories

  • Defects
  • Ideas
  • Development
  • ☑ Archive

Categories

  • Inquiries

Categories

  • Professional
  • Management
    • Agile
  • Requirements
  • Design
  • Development
    • Frontend
    • Backend
  • Testing
  • Operations
    • Hosting
  • Atlassian
  • Security
  • E-commerce
    • CRO
    • SEO
  • Interesting

Categories

  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce

Forums

  • General
    • Open Forum
    • Support
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Test / QA
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
    • Invision Community
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Forums
  • Destiny 2's Discussions
  • The Journey's Discussions
  • Cinephilia's Topics
  • Diablo 4's Diablo 4 Topics
  • Shadownessence's Topics
  • sensory hyperreactivity's Topics
  • Wolcen's Wolcen Topics
  • Quality Assurance Heroes's QA Topics
  • Visual Studio Code's Forum
  • Adobe Illustrator's Adobe Illustrator Forum
  • Sketch Guru's's Sketch Topics
  • Requirements & test management in Jira's Topics
  • Microsoft Teams's Microsoft Teams Discussions
  • Figma's Figma Topics
  • Microsoft Planner's Microsoft Planner Topics
  • Psychology's Psychology Topics
  • Microsoft Word's Microsoft Word Topics
  • Microsoft Powerpoint's Microsoft Powerpoint Topics
  • WordPress Devs's Wordpress Topics
  • Ornamental Design's Ornamental Design Topics
  • Adobe Photoshop's Photoshop Discussions
  • Agile 2's Agile 2 Topics
  • Agile 2's Agile 2 Principles
  • Microsoft Outlook's Outlook Topics
  • My Book's Discussions
  • Outriders's Outriders Discussions

Categories

  • Jimi's Files
    • Curriculum vitae
    • Presentations
    • Certificates
  • Management
  • Requirements
  • Design
    • Fonts
  • Code
  • Test
  • Operations
  • Atlassian
    • Certificates of Excellence
  • Security
  • Ecommerce
  • Invision Power Services
    • JWSE Support Tickets
    • JWSE Task Management
  • Shadownessence's Files
  • WordPress Devs's Wordpress Files

Calendars

  • Project: JWSE Workboard
  • Project: JWSE Workboard
  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Design Events
  • Development Events
  • Test Events
  • Atlassian Events
  • Operations Events
  • E-commerce Events
  • Destiny 2's Events
  • The Journey's Events
  • Cinephilia's premieres
  • Diablo 4's Diablo 4 Events
  • Agile 2's Agile 2 Events

Blogs

  • How to start your own blog
  • Sketch Blog
  • Building The Site's Blog
  • Destiny 2's Destiny 2 ramblings
  • The Journey's Stories
  • Diablo 4's Diablo 4 blog
  • Sketch Guru's's Sketch News
  • Requirements & test management in Jira's News
  • Agile 2's Agile 2 Blog

Categories

  • Personal
    • Humor
    • Music
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
  • Destiny 2's Videos
  • The Journey's Videos
  • Cinephilia's Trailers
  • Diablo 4's Diablo 4 Videos
  • Wolcen's Wolcen Videos
  • Visual Studio Code's Videos
  • Adobe Illustrator's Adobe Illustrator Videos
  • Sketch Guru's's Sketch Videos
  • Requirements & test management in Jira's Videos
  • Microsoft Teams's Microsoft Teams Videos
  • Figma's Figma Videos
  • Microsoft Planner's Microsoft Planner Videos
  • Psychology's Psychology Videos
  • Microsoft Word's Microsoft Word Videos
  • Microsoft Powerpoint's Microsoft Powerpoint Videos
  • WordPress Devs's Wordpress Videos
  • Ornamental Design's Ornamental Design Videos
  • Adobe Photoshop's Photoshop Videos
  • Agile 2's Agile 2 Videos
  • Microsoft Outlook's Outlook Videos
  • Outriders's Outriders Videos

Categories

  • Movies
    • Action Movies
    • Adventure Movies
    • Animated Movies
    • Comedy Movies
    • Crime Movies
    • Drama Movies
    • Fantasy Movies
    • Horror Movies
    • Romance Movies
    • Sci-Fi Movies
    • Thriller Movies
    • Western Movies
  • TV Shows
    • Action TV Shows
    • Adventure TV Shows
    • Animated TV Shows
    • Comedy TV Shows
    • Crime TV Shows
    • Drama TV Shows
    • Fantasy TV Shows
    • Horror TV Shows
    • Romance TV Shows
    • Sci-Fi TV Shows
    • Thriller TV Shows
    • Western TV Shows

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

  1. 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
  2. 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.
  3. I often get questions on how I think the best setup for Jira and Confluence should look when I meet organizations. Because of that I will make a series of posts about this where I setup Jira and Confluence from scratch. This will include not just how I do things, but also the thought behind it. I hope you will find this useful for setting up your own setup in Jira and Confluence. This series will be divided into several parts. This is because adding every step in a single post would make for a very long blog post. Dividing into a series also make it easier for you to look at specific parts that is most interesting for you at the moment. The parts that I have in mind could change as I write the series, but at the moment the plan is this: Part 1: Defining the tools Part 2: Defining Jira Issue Types Part 3: Defining Jira Issue workflows Part 4: Defining Jira Screens & Custom fields Part 5: Defining Jira security & access Part 6: Defining Confluence Information Structure Part 7: Defining Confluence Requirement Templates Part 8: Defining Confluence Design Templates With the setup completed in Jira and Confluence, I will probably add a second series called "Work processes in Confluence & Jira - From Need to Deploy" where we go through how to use the setup from a practical point of view. It will be a more generic process, so it can be used in any methodology with some minor tweaks. If anyone wants, I could also add a post about how to use the power of Jira and Confluence for programmers without ever leaving your IDE. Is there anything you miss from this series that you feel I should add?
  4. 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
  5. A product manager is the person who identifies the customer need and the larger business objectives that a product or feature will fulfill, articulates what success looks like for a product, and rallies a team to turn that vision into a reality. After 10 years of studying the craft of product management, I’ve developed a deep understanding of what it means to be a product manager.
  6. Priorities View File A simple icon set for Priorities I use in my own Jira instance. It uses colors to indicate priority / Severity ranging from full red in the blocker and then scale down in the color range down to purple for the lowest. The symbols are simplified as well to make them as visible as possible. Included: Blocker - Full red with a blocked icon as the indicator. Highest - 7 sided background in deep red with a white exclamation mark. High - Orange triangle pointing upwards. Medium - Green circle Low - Blue triangle pointing downwards. Lowest - Three purple dashes. Submitter ©Jimi Wikman Submitted 02/04/2020 Category Graphics
  7. In the coming months we will see some changes to the navigation in Jira and Confluence for the cloud versions. This after a round of feedback was done in July this year on the new experience. This change will roll out slowly and you can delay the change if you need time to prepare the users for the change. There has been some negative feedback regarding the current navigation in Jira and Confluence cloud as it is a bit difficult to use. This is why a new experience was designed and tested during the summer by 350+ users. The feedback on the new navigation was positive and so now it is going live to cloud users in a slow rollout. This is a rollback to the old navigation experience which is good as it will make the transition from Server and DC versions easier. I like the new apps and people sections in the navigation as well. That should make it easier to group things to keep navigation organized. The fact that Jira and Confluence now get a uniform navigation is also excellent. On the documentation page for the new Confluence navigation we find more details on the new navigation and it's design. App switcher - Switch to other Atlassian Cloud apps, like Jira, and go to recent Confluence spaces and Jira projects. Confluence logo and name - Click this to go to the Confluence Home page. Home - Begin your Confluence journey and reorient yourself when you’re moving on to a new piece of work by easily accessing the spaces, pages, and updates that are important to you. Recent - Access pages you’ve recently visited and worked on as well as pages saved as draft or starred. Spaces - Get to spaces you’ve recently visited and starred. People - Search for people on your site by visiting the people directory. Apps - Access content from apps like Analytics, Calendars for Confluence, or Questions for Confluence. Create - Click to create a new page, either blank or from a template. Search - Find pages, spaces, and other content. Notifications - Find out what's happening in Confluence and other Atlassian apps, like Jira. Help - Get online help, and find out what's new in your Atlassian Cloud apps. Your profile and settings - Go to or create your personal space, find out about the new Confluence experience, and adjust your Confluence settings. New Homepage In addition to the new navigation we will also get a new start page, or home page as it is called. This will appear in both Jira and Confluence cloud at the same time as we will see the new navigation. For Confluence it will give an overview over: Spaces - Get back to the spaces you care about, starred or recently visited Recent pages - Find pages you’ve drafted, recently published, visited, or starred All updates - View the updates across your site The Home page for Jira follow that principle, but is a bit slimmed down. I think there are more things that can go in this view and I hope we will see the same structure as for Confluence in the future. So instead of spaces we would have projects and then I would like to have a list of favorite boards somewhere.
  8. The Roadmap feature in Jira Cloud's NextGen projects is getting three new features. While all good additions, the question still remain who these new features are for and to what extent these new features will make people move over to NextGen projects. NextGen for Jira Cloud is in a strange place as it is not really defined what is can and should be used for. The Roadmap feature is in a similar place as it fall somewhere between Portfolio for Jira and the Roadmap planner macro in Confluence. These 3 new features are an improvement and a good indication on where Atlassian are going. The question is just how fast these new features are coming out and if it appeal to the target audience. Drill down into the details The first feature is the ability to open up the Epic and see the underlying tasks. This is a much needed feature that was heavily requested and also one I spoke with Atlassian about earlier this fall. This is a good feature and a good step to improve the roadmap, but is still in need of further refinement. We still only have Epics as the starting point, which will limit the use of Roadmaps. Opening up the subtasks will only show their status at the moment, which is useful, but not what many want. Many still want a Gant view where the sum of the subtasks should make up the time in the Epic. This is not possible at the moment and I find it interesting that Atlassian has chosen to follow an Agile first approach to the Roadmaps, which means it will not be very useful for the majority of the companies using Atlassian's products today. Add new tasks directly in the Roadmap Another great feature that was much requested is the ability to create new sub tasks directly in the Roadmap. This way we can build up a full stack of tasks for a project in one view, which is excellent for portfolio and project planning purposes. The fact that we do not get full Gantt view for the sub tasks makes this a little less useful for time and resource planning however. Filter your Epics and Tasks The ability to use different filters is a must for any Portfolio, but even roadmaps benefit from filtering options. In this release we get the filters for issue status and assignee, which is a good start. I would like to see some more filters like dependencies and of course issues that are behind the time schedule. The question is just who this Roadmap feature is for though as then we are moving more into project management and Portfolio management and Atlassian has previously stated that the Roadmap is for teams. It's a good start, but... I am still not sure where NextGen projects are heading, which means it's hard to say if the features are great or poor. We know that Roadmaps will be ported over to the Classic project types as well, but that will make things even more confusing. This is unfortunately a common issue with Atlassian as they are getting more and more fractured with no clear indication on structure or strategy. Roadmaps for me is something that should stay as a team tool for small teams to give an overview of the current work. To cater to that need Roadmaps could benefit from a few changes. The first would be to change the basic structure and allow the view to be in any level. That means that I should be able to use Stories rather than Epics as Epics are just containers and not work tasks. The majority of issues are not connected to Epics in most teams, especially if you work in a Kanban setting for continuous improvements for example. The second would be to go full gantt, or rather to give the option to go full gantt. Not every team need or will use estimation in issues, but most do. Without a full gantt the view of issues will not be as useful as a progress overview tool. It's like saying that I have a container of a certain size and in that container I have put five items. On the question if the items will fit my only answerr will be "I don't know", which is in many organizations not an acceptable answer. The third would be to add dependencies on issues and not just on Epics and extend the data to also show data from other projects. In most organizations dependencies are not within the team itself, but to surrounding teams. Even if the view is for the team it makes sense that I should be able to see what other teams could be affected. The fourth would be to ensure that Roadmaps becomes a granular part of a larger view. Right now it is an isolated feature, which means that we will have different data for different levels of the organization. This will lead to miscommunication within the organization as teams will say Epics, which will mean something very different to Program managers and Portfolio managers and so on. As more and more organization add SAFe to their processes it is important that the team view is part of the greater whole. I am sure we will so many great additions to Roadmaps in 2020 and hopefully many of the questions we have regarding Roadmaps and NextGen projects will get answers then. Until then these three new features are welcome additions that I am sure will help many teams improve their work processes.
  9. In the last article we talked about defining workflows, so now it's time to talk about defining custom fields and screens. The custom fields is where most companies make many mistakes by trying to build new ways for Jira to work and screens almost no one seem to use. Let us change that, but first let us go over what these things are. We start with custom fields. Custom fields explained Custom fields are extensions of the data built in to Jira by default. This allow you to make adjustments to your Jira instance in the event that you need it. Custom fields comes in many pre-defined formats such as date fields, droplists, labels and even cascading select lists. In short you can model the data you work with pretty much any way you want. That is usually also the big problem with custom fields... Custom fields are defined just like most things in Jira using attaching the custom fields to a scheme. For custom fields this is called Field Configuration Schemes. These schemes connect a custom field configuration with the custom fields. This field configuration is what defines how each custom field should be used in a specific context. This allow you to have different behavior and configuration for the same fields. Custom fields - new data objects that extend the database model. Field configuration - Definition of configuration and behavior for custom fields. Field configuration schemes - map fields with field configurations. This is attached to a project to define that projects field configuration. Impact on performance Custom fields have an impact on performance. Period. Anyone who think otherwise do not understand how custom fields work or what impact they have on the system. Jira uses an indexing system that cache data in order to quickly find the relevant data you search for. For this Jira uses Apache Lucene, an open source high-performance, full-featured text search engine library written entirely in Java. Whenever you use a board, filter, dashboard or search in Jira you will use Lucene. Every custom field you add will grow the data exponentially in the index as it will be added to every single issue in Jira, even if that issue does not have any data in the field. Just by adding custom fields you will see an impact on performance and if you are careless about the size of your projects or do not manage your releases properly, then you can render the Jira instance almost unusable dye to loading time. Use custom fields with care! Mandatory fields impact Mandatory fields can be set in the field configuration. This will make a certain field mandatory that you have to fill in. This may sound like a great way to force the users to fill in the data you want them to, but in reality it is causing serious issues, especially when working with any form of integration. When you have integrations that send data to Jira, then do not use mandatory fields, or make sure that it is mandatory for all projects. Having multiple versions of what data is mandatory is a sure way to make integrations fail. This is because we set up a condition that say that unless this data is part of the data you want to submit, it will fail. The most common reason for using mandatory fields is because the teams do not understand why they should fill in the data. This is because of poor education on how the workflow should be done or because the way it is designed makes no sense to the people actually doing the work. This should be solved on a method and process level and not in the tool. Building new systems in Jira with Custom fields The biggest failure I see in Jira is when custom fields are used to extend the capability of Jira to something it is not built for. The most common thing I see is that a story is used as a business need and then kept all the way though deployment. I understand the thought behind it, but the execution will require dozens if not hundreds of new fields and it will just become a mass of data that is almost impossible to work with. Jira is first and foremost a development tool. It starts with a need that has been transformed into a work order for the development team. In many cases you also have test included in Jira. Often as a plugin or just in the workflow itself. That is all Jira should do as there are other tools that should handle business need, requirements as well as build and deployment. In large organizations this behavior is very dangerous. I often see people getting burned out or just give up an aspiration of coherent and logical way of working as the systems evolve to grotesque monsters no one really understand or want. Do not build new ways of working, stick to the standards that exists and you will be much happier. If you are going to extend the capabilities of Jira, then always use a Jira designer that can design the system globally for all users. NEVER allow teams and groups within the organization to design on their own, unless they are an isolated group that never need to work with outer teams or systems. That lead to a fragmented way of working that will cost millions to repair in the future. One field to "always" use Despite all the issues that comes with custom fields there is one field I always think makes sense. There are others of course because in all organizations there are a few fields that makes perfect sense and that really improve the way of working. One such field is "Team", but only if you are not using a plugin like Portfolio for Jira as that already have teams built in. The reason why team is useful in almost any scenario is because it allow you to work across Jira Projects in a standardized setup. This way we can avoid Jira projects with hundreds of people and instead work with boards. Using this field you can assign issues to teams rather than people allow for cross project assignments. We will discuss this more in future articles. Screens and why they matter Where custom fields are abused to the point of absurdity in many organizations, screens are barely used at all in my experience. This is strange as screens are very useful for making sure you are working with the right data at the right time. This will make things much easier when creating new issues or allow you to have certain data filled in during transitions in the workflow. Screens are divided into 3 views: View screen - The view used when you look at an issue i Jira. Edit view - The view showed when you edit the issue. Create View - the view when you create an issue. This allow us to focus the information in creation view for example to make sure that we only see the fields that we actually need, and then have all information in view and edit. When defining screens we have three parts to do so: Screens - Where we define what data should be available in the screen. Screen Schemes - Where we define what screens should be used for the View/Edit/Create views Issue Type Screen Schemes - Where we define what screen schemes should be used for the different issue types. One common use of defining screens is to define the create view for defects. This allow for a more focused defect report process where only the fields we really need is shown when creating the defect. Once created it will allow for all the same fields as a story since it is actually a story that describes a need that has yet to be addressed. Defining fields in a screen So, first we start by defining the screens. First we want to create a new screen for defects so we can define the fields we want when creating new defects. We go to Jira Settings ->Issues -> Screens where we find all our current screens. Then on the top right we can click the button to create a new screen. Add a name and a description and then click add. This will take us to the screen configuration page where we can define the data we want. Since this is a defect we want to capture the problem, where the problem occurred and also who should get the defect to look at. We define the fields like this: Issue Type* - Needed to we can set this as a defect. Reporter* - So we know who reported the defect for follow up. Summary* - The headline that summarize what the problem is. Environment* - Where was the defect found (test, pre-prod, dev and so on). This is needed for defects, but if this had been for production incidents we would not need this field as it is always in production. Affects version* - what code base or release is this related to so we know in what code we should look for it. Description* - This is where the defect is described. It should be steps to reproduce and expected results. Attachments - Pictures or videos that help describe the defect. NEVER upload office files here as you need to download them, which is a horrible way to work. Assignee - Sometimes used to assign a defect to a QA lead for example or a Project manager for attention. Responsible team - When the responsible team in known it can be added to the defect as well. Priority / Severity - How bad the defect is and not how soon it should be fixed. Components - what area of the system the defect affects. Labels - for labeling. Linked issues - If there are other issues that are relevant to the defect. Epic Link - If you use epics to group things. * These fields are mandatory. The rest can vary depending on your work process. It is important that these fields are also available in the default screen. If they are not present there they will not show as we do not have custom screens for the view or edit screens in this example. If you forget to add them, then do not worry. The data will still be there, but it will not show until you have added the fields to the screen. Defining views for Defects With this done our next step is to define the three views for defects so we later can attach it to the right issue type. We do this by going to Jira Settings ->Issues -> Screen Schemes and click on the button saying Add Screen Scheme. Add a name and a description, then set the default screen. This should not be the new screen we created as that one will only be used for the create action. You can change this later if you want. With that in place we come to the configuration page where we assign screens to the three actions we have (Create, View, Edit). By default you have one screen defined for all actions here, which is the one selected when creating the screen scheme. Now we will add our new screen to the create action and we do that by clicking the top right button that says "Associate an issue operation with a screen". Now you can select one of the three actions and a screen. We select the create action and connect that to our new defect screen and click add. Defining screen schemes to defects Now that we have the screen configured we need to add it to the correct issue and to do that we first need to create a issue Type Screen Scheme. We do this by going to Jira Settings ->Issues -> Issue Type Screen Schemes. Again we click the add button in the top right and add a name and description. This time we also can select a default screen scheme so we add the default screen sheme that will be used for all actions rather than the custom field we created for creating new defects. This can be changed later if you want. Once we have this created we get into the configuration screen. Here we will have a default screen scheme set for all issue types. Now we will need to add the new screen scheme we created for defects here. We do that by clicking the button in the top right that says "Associate an issue type with a screen scheme". Select the issue type Defect and then the screen scheme we created earlier and click add. ...and we are done. From now on we will always see the fields we have defined in the Defect screen when we create new defects. We can edit the fields as we see fit and it will not affect any other screens. Since we did not create custom screens for edit or view it means that we will see the same fields as for all other issues once the defect has been created. Focus information when needed As you can see it is not very complicated to add new screens, but they can add quite a bit of focus to your workflow. For this example we created a focused screen for reporting defects, but you will most likely want additional screens. One such screen that I almost always add is the Resolve screen that shows up when you resolve an issue. This is done by adding a trigger in the workflow that add a screen on an action as a popup. We will cover that setup in another post. I hope this was useful for you and in our next article we will discuss Jira security & access. In case you have missed any of the previous articles you can find them all here.
  10. This is a repost from Atlassian's blog where the latest updates to the Atlassian cloud platform is posted. It is reposted here since the Atlassian blog does not have an RSS feed and so we can discuss the changes to the Atlassian Cloud architecture. You can follow these posts withe the tag "atlassian cloud changes". 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 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 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 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. Set your language and time zone for Jira and Confluence in your Atlassian account profile Rather than individually setting your language and time zone in Jira and Confluence, these preferences will soon come from your Atlassian account profile. Visit your account preferences to update these settings. It may take up to 10 mins before your updated preferences are reflected in Jira and Confluence. 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 issue view: Print an issue or export it to Microsoft Word or XML Print or export individual issues in the new issue view. Open an issue and choose more actions (•••) at the top-right to print it or export it to Microsoft Word (DOC) or XML format. Changing the "Issues and filters" navigation item to "Filters" In preparation for the rollout of our improved navigation for Jira Cloud, we've updated the "Issues and filters" menu item in the Jira sidebar to simply be "Filters." When we move to the new horizontal navigation, this name will better reflect what you'll find in the menu—filters, filters, and more filters. This is purely a label change at this point, and won't change any functionality. New user profile cards 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). Next-gen: Epic panel in backlog You can now manage epics on the backlog of your next-gen project via the Epics panel, similar to how epic management works in classic Jira Software projects. Changes you make in the panel on the backlog will reflect on the Roadmap, and vice-versa. Advanced search (JQL): Search for content updated by a specific user Use the updatedBy() function to search for issues that were updated by a specific user, optionally within the specified time range. For example, if you want to find issues updated by John Smith between June and September 2018, enter issuekey IN updatedBy(jsmith, "2018/06/01", "2018/08/31"). Read more about the updatedBy() function. 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. GitHub app on the Atlassian Marketplace 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. Next-gen: Roadmap issue hierarchy You can now expand an epic on your roadmap to see its child issues and their statuses. Learn more about managing epics on the roadmap. Next-gen: Create child issues on your roadmap You can now add child issues directly on your roadmap. Just hover over an epic, click the + icon, and give your issue a name. Learn more about managing epics on the roadmap. Next-gen: Environment system field in JSW Add Jira’s built-in Environment field to your issue types in next-gen projects. In your project, go to Project settings > Issue types and drag the Environment field into the Description section of the issue layout. Jira Service Desk New issue view for Jira Service Desk 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 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 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. Maintenance complete on the customer portal user profile page We have just completed some maintenance on the customer portal user profile page. We also introduced a new layout that is easier to use on mobile devices. Go team! Easier configuration for the new issue view 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. Next-gen projects: Approve or decline requests You can now add an approval stage to requests that should be approved before they’re resolved in next-gen projects. If a request has an approval stage, approvers can approve or decline the request from the issue view. Add an approval stage to a workflow by going to Project settings > Request types and then clicking Edit workflow. Learn more Global create can select request type and raise on behalf of You can now create a request on behalf of your customers and set them as the reporter. Use the global create button ( + ), then select Raise this request on behalf of and add in your customer's email. Introducing multi-line fields to the issue view in next-gen projects You can now add multi-line fields to the issue view. These fields communicate long-form information to your team members and aren’t visible to your customers. To add multi-line fields, go to Project settings > Request types and add fields to the Description fields bucket. Confluence Your editing experience just got an upgrade The new Confluence editor allows anyone to create beautiful, powerful pages effortlessly. Check out the editor roadmap to learn more. We're extending editing improvements to all pages on Android 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. Annotate images in the new editor Annotate images by adding text, inserting shapes and lines, using brushes, or adding a blur to a certain area. Confluence Cloud recent pages drawer 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 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 Jira issue URLs are converted to smart links When you paste a Jira issue link into a Confluence page, the URL is converted to a smart link that displays the page icon and the page title. This works if the Jira and Confluence sites are linked or if they are both cloud versions. Convert pages to use the new editor You can now convert your existing pages that were created using the legacy editor to use the new editing experience! Learn more Confluence navigation just got better Get to information faster with improved navigation – making what you need visible from anywhere in Confluence. Learn more Align and resize images in tables in the new editor When images are inserted in table cells, you now have the ability to align and resize them. Portfolio for Jira plan macro 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. Improved expand element replaces the macro Content creators just got a better way to control the way information is presented. The existing expand macro has been replaced with a quicker, easier way to include the expand functionality. Insert the improved expand element using /expand or by inserting the element from the editor's Insert toolbar. Bitbucket New Code Review - Limit the amount of rendered diff content Limits the amount of pull request content rendered in the diff and file tree to improve browser performance. Limits include the overall # of files and # of lines for the entire diff. Learn more
  11. Version 1.0.0

    190 downloads

    A few icons for issue types in Jira as presented in:
  12. Requirements in Jira has long been a wish for many Jira users. Many have tried it and many have failed because Jira is not designed to work with controlled requirements. Because of this I have always suggested to work with requirements in Confluence, but with RTM from Deviniti, I might change my mind about that. I am a certified requirements analyst and as someone who works in all positions in a development process I know the importance of good requirements. While good communication is key for a good workforce it does not remove the need for controlled requirements. In Jira you can setup requirements as part of a workflow or as a separate issue type, but the experience is far from controlled. When I saw RTM from Deviniti for the the first time I was intrigued. It looked very similar to older systems like HP QC (now Micro Focus Quality Center) in it's structure. I installed it on my Jira instance and have played around with it for a while now. So far I am very impressed, especially since Deviniti have confirmed that some of the things I miss are in their roadmap. Requirements & test management in Jira RTM comes with five main modules, plus a bunch of reports. The modules are all customizable so you can define what issue types you want to map with what module. This is great because that way I can map towards already existing issue types, or custom make new ones if needed. For Defects I can even map multiple issue types, which is great if you like me use both Defect and Incident. This is also possible for Requirements which is necessary for working with multiple types. In my setup I only have functional and non-functional requirements, but you can add more if you like. The RTM Requirements module This is the exciting part of RTM! Working with requirements in RTM feels just like in ALM or other older systems, but with the ease and great usability of Jira. You can quickly create a tree structure and rearrange the tree is easy and fast with drag and drop. Existing requirements can be imported using the import function that is located in the left column where the tree is under the three dots. You can customize the tree structure in the RTM configuration that is located under project settings. There you can select if you want auto numbering and if you want the issue number to be written out or not. While we still miss a few things (see below) this is really a great start. It is by far the best requirements app for Jira I have seen so far. The RTM Test Cases Module Test cases are reusable tests with test steps that you use in the test plans to perform tests. RTM is competing with some big shoes in the test department, but they hold up pretty good here. I like the configuration for the test steps that you have in the RTM configuration under project settings where you can modify the columns for the test steps. This allow me to define what columns I want with ease. You can also select what the starting status is, but right now you can not add or edit the standard statuses. As with all modules you can import existing test cases using the import function above the tree structure where you see the three dots. The RTM Test Plans Module Test plans are equally easy to create and manage. In the test plan you connect test cases and test executions to get the full overview of the test scope and result. In the overview of the test cases connected to the test plan you can change the order, create new test cases or add test cases. To me this gave a very good overview of the scope, what was actually tested and I have plenty of room to describe the test plan without cluttering things up. The RTM Test Executions Module The test executions module allow you to quickly execute test plans and you can structure them the same way as all the modules. You can re-execute test executions, which then create a new test execution that you can place in a folder directly. This is great for example smoke test that you want to run frequently. There are some things I think can be improved visually, but overall this works pretty well. The RTM Defects Module The Defects module give you an overview of the defects in the projects. If you are adding RTM to an existing project where you already have defects, then you can easily import them using the import function. It is a bit hidden, but you find it in the left column under the three dots. The Good and The Bad There is not a whole lot to say on the negative side of this because it works very well. I tested this with Portfolio for Jira and the result is amazing. You easily get the structure you need for a full parent-child tree structure and the modules in RTM provides a great focus area for requirements and test. Version management What I miss are the version management that absolutely must be there. This is one of the things that are on the roadmap for the future. Hopefully this can tie into some form of approval process to better control changes. This is important for large organizations, but also for non-functional requirements that usually are global. Acceptance Criteria This is also a thing that is currently missing and also on the road map for future updates. If these could work the same way as the test steps work today, or maybe even having them as separate entities like test cases, then this would be amazing. This would allow for really powerful connectivity between not just requirements and test, but also defects and requirements. Import from other projects One of the things I miss is the ability to import from other projects. This is especially useful for non-functional requirements that are often shared between many projects. I would like to be able to import these as read only so I can have them as part of the requirement structure, but not be able to edit for example legal requirements. I can make a requirement in the existing project and link for now, but I think import as read only would be a better solution. Quickfilters in Defects module The only thing I miss here is the possibility to add quick filters, just like in boards. This would allow me to better use this view based on my need. I found myself jumping to filters a few times to get a more focused view and with quick filters that would not be necessary. The Module Templates While the modules are not terrible in terms of visual they could improve a bit. Things are a bit cluttered and the tabs are not super obvious at first glance. Here I would like to see a slight update using Jira standards, but we also need templates to add custom data for example. Based of the structure with tabs I think it would be possible to use the standard view design and just split it in the different tabs for starters. Better integration with Confluence If I add a Confluence link directly into the issue itself, then it show up as just Wiki page. This is not very good as I want to see the name of the page so I know what page it is referring to. Other Apps support Right now I can't add other apps to the modules view, which is a bit of a problem for the requirements part especially. I often add designs using Invision prototypes and if that is not shown in the modules view, then I have to jump back and forth between the issue view and the module view. That is not good and I think this need to be added to the modules template designs. Test Executions UX and Visuals The test executions are a bit clunky when it comes to the UX. I find myself getting a bit lost as things happen without me being in control and I sometimes end up in the test issue view instead of the execution view. I would like to keep the execution summary in the header so it remain consistent and so I can come back to the execution overview instead of the issue view. The statuses are not tied into a workflow, which means that you need to skip back and forth to manage your test executions. A mapping in the settings would be nice so I can map execution statuses to workflow statuses. Also, there might be a good idea to separate statuses from resolutions to keep in line with Jira standard. Colorful folders This is just a cosmetic thing, but I like to be able to differentiate folders using colors and icons. This makes it a whole lot easier to quickly find the correct are, especially for large trees that often occur in requirements for larger systems. it would be very nice to have the option of selecting colors of the folders and special icing on the cake if I can select an icon as well. It would be easy to just use FontAwesome for example and allow the user to pick the icon from the font set. My opinion on RTM from Deviniti This is by far the most complete solution for a functional way of working with requirements and test in a controlled way. It still need some work here and there, but I will recommend this to all my clients as it stands today. Even without version management or dedicated sections for acceptance criteria it is still far, far better than what most people have today. When this product get more polished I think this will be one of the must have apps in pretty much every Jira instance. I like it. A lot.
  13. My assignment is to set up, configure and design an Atlassian setup as a proof of concept for the new work processes.
  14. The assignment is to conduct a prestudy to assess how to add Jira and Confluence as standard tool within the organization. This assessment is delivered as a suggested implementation plan with timeline, budget and activities required.
  15. Requirements in Jira has long been a wish for many Jira users. Many have tried it and many have failed because Jira is not designed to work with controlled requirements. Because of this I have always suggested to work with requirements in Confluence, but with RTM from Deviniti, I might change my mind about that. I am a certified requirements analyst and as someone who works in all positions in a development process I know the importance of good requirements. While good communication is key for a good workforce it does not remove the need for controlled requirements. In Jira you can setup requirements as part of a workflow or as a separate issue type, but the experience is far from controlled. When I saw RTM from Deviniti for the the first time I was intrigued. It looked very similar to older systems like HP QC (now Micro Focus Quality Center) in it's structure. I installed it on my Jira instance and have played around with it for a while now. So far I am very impressed, especially since Deviniti have confirmed that some of the things I miss are in their roadmap. Requirements & test management in Jira RTM comes with five main modules, plus a bunch of reports. The modules are all customizable so you can define what issue types you want to map with what module. This is great because that way I can map towards already existing issue types, or custom make new ones if needed. For Defects I can even map multiple issue types, which is great if you like me use both Defect and Incident. This is also possible for Requirements which is necessary for working with multiple types. In my setup I only have functional and non-functional requirements, but you can add more if you like. The RTM Requirements module This is the exciting part of RTM! Working with requirements in RTM feels just like in ALM or other older systems, but with the ease and great usability of Jira. You can quickly create a tree structure and rearrange the tree is easy and fast with drag and drop. Existing requirements can be imported using the import function that is located in the left column where the tree is under the three dots. You can customize the tree structure in the RTM configuration that is located under project settings. There you can select if you want auto numbering and if you want the issue number to be written out or not. While we still miss a few things (see below) this is really a great start. It is by far the best requirements app for Jira I have seen so far. The RTM Test Cases Module Test cases are reusable tests with test steps that you use in the test plans to perform tests. RTM is competing with some big shoes in the test department, but they hold up pretty good here. I like the configuration for the test steps that you have in the RTM configuration under project settings where you can modify the columns for the test steps. This allow me to define what columns I want with ease. You can also select what the starting status is, but right now you can not add or edit the standard statuses. As with all modules you can import existing test cases using the import function above the tree structure where you see the three dots. The RTM Test Plans Module Test plans are equally easy to create and manage. In the test plan you connect test cases and test executions to get the full overview of the test scope and result. In the overview of the test cases connected to the test plan you can change the order, create new test cases or add test cases. To me this gave a very good overview of the scope, what was actually tested and I have plenty of room to describe the test plan without cluttering things up. The RTM Test Executions Module The test executions module allow you to quickly execute test plans and you can structure them the same way as all the modules. You can re-execute test executions, which then create a new test execution that you can place in a folder directly. This is great for example smoke test that you want to run frequently. There are some things I think can be improved visually, but overall this works pretty well. The RTM Defects Module The Defects module give you an overview of the defects in the projects. If you are adding RTM to an existing project where you already have defects, then you can easily import them using the import function. It is a bit hidden, but you find it in the left column under the three dots. The Good and The Bad There is not a whole lot to say on the negative side of this because it works very well. I tested this with Portfolio for Jira and the result is amazing. You easily get the structure you need for a full parent-child tree structure and the modules in RTM provides a great focus area for requirements and test. Version management What I miss are the version management that absolutely must be there. This is one of the things that are on the roadmap for the future. Hopefully this can tie into some form of approval process to better control changes. This is important for large organizations, but also for non-functional requirements that usually are global. Acceptance Criteria This is also a thing that is currently missing and also on the road map for future updates. If these could work the same way as the test steps work today, or maybe even having them as separate entities like test cases, then this would be amazing. This would allow for really powerful connectivity between not just requirements and test, but also defects and requirements. Import from other projects One of the things I miss is the ability to import from other projects. This is especially useful for non-functional requirements that are often shared between many projects. I would like to be able to import these as read only so I can have them as part of the requirement structure, but not be able to edit for example legal requirements. I can make a requirement in the existing project and link for now, but I think import as read only would be a better solution. Quickfilters in Defects module The only thing I miss here is the possibility to add quick filters, just like in boards. This would allow me to better use this view based on my need. I found myself jumping to filters a few times to get a more focused view and with quick filters that would not be necessary. The Module Templates While the modules are not terrible in terms of visual they could improve a bit. Things are a bit cluttered and the tabs are not super obvious at first glance. Here I would like to see a slight update using Jira standards, but we also need templates to add custom data for example. Based of the structure with tabs I think it would be possible to use the standard view design and just split it in the different tabs for starters. Better integration with Confluence If I add a Confluence link directly into the issue itself, then it show up as just Wiki page. This is not very good as I want to see the name of the page so I know what page it is referring to. Other Apps support Right now I can't add other apps to the modules view, which is a bit of a problem for the requirements part especially. I often add designs using Invision prototypes and if that is not shown in the modules view, then I have to jump back and forth between the issue view and the module view. That is not good and I think this need to be added to the modules template designs. Test Executions UX and Visuals The test executions are a bit clunky when it comes to the UX. I find myself getting a bit lost as things happen without me being in control and I sometimes end up in the test issue view instead of the execution view. I would like to keep the execution summary in the header so it remain consistent and so I can come back to the execution overview instead of the issue view. The statuses are not tied into a workflow, which means that you need to skip back and forth to manage your test executions. A mapping in the settings would be nice so I can map execution statuses to workflow statuses. Also, there might be a good idea to separate statuses from resolutions to keep in line with Jira standard. Colorful folders This is just a cosmetic thing, but I like to be able to differentiate folders using colors and icons. This makes it a whole lot easier to quickly find the correct are, especially for large trees that often occur in requirements for larger systems. it would be very nice to have the option of selecting colors of the folders and special icing on the cake if I can select an icon as well. It would be easy to just use FontAwesome for example and allow the user to pick the icon from the font set. My opinion on RTM from Deviniti This is by far the most complete solution for a functional way of working with requirements and test in a controlled way. It still need some work here and there, but I will recommend this to all my clients as it stands today. Even without version management or dedicated sections for acceptance criteria it is still far, far better than what most people have today. When this product get more polished I think this will be one of the must have apps in pretty much every Jira instance. I like it. A lot. View full blog article
  16. As an Atlassian Platinum Solution Partner Enterprise and a Platinum Top Vendor in the Ecosystem, we’ve been working hard on enhancing the use of Jira Software for over 2500 business teams around the globe. This app adds Requirements, Test Plans, Test Cases and Test Executions panels to your software project in Jira and thus allows you to track the whole development process from collecting requirements to going to production in a single place.   Try the app out for free on the Atlassian Marketplace:    Follow us on other channels: https://www.linkedin.com/company/devi... http://twitter.com/deviniti_voice http://facebook.com/DevinitiPL
  17. Patrik

    Patrik Ohlsson

    I am a senior Test management consultant with proven ability when it comes to helping development teams deliver tested working software faster with minimal impact on time to market. I like to think I have a professional and humble approach with the ability to perform well under pressure and as a a person I have gotten feedback that I'm easy to work with and to gain confidence in. I like to set set goals and then achieving them. Areas of expertise: Acceptance testing, Business analysis, Team lead, E2E Testing using automation, Continuous testing and much more. I have: 20+ years QA experience from retail, telecom, finance and travel industry. 10+ years experience working as a consultant in agile projects 6+ years experience from various E-commerce implementations On a personal note I live south of Stockholm with my family and I enjoy sports, traveling and movies.
  18. Scaled Agile Framework and PI planning in BigPicture [Jira]. A quick tutorial. 1:03 PI planning. Product roadmap 2:11 Inputs and deliverables 2:47 Product backlog (Scope, Epic - Feature - Story, WSJF) 3:48 Program Board 4:04 Team breakout session (capacity planning, decompose features into stories, planning iterations, dependencies) 6:02 Objectives 6:36 Scrum of Scrums 6:53 Inspect and Adapt 7:43 How does BigPicture 8 contribute to SAFe®? See SAFe® whitepapers: https://softwareplant.com/safe/
  19. Version 1.0.0

    10 downloads

    We go over transitional and producing workflows, designing issue types and how to divide projects into a scalable solution that also can be used for SAFe. Stockholm AUG Leader Jimi Wikman show the setup he has built based on his experience as a project leader, release manager, designer, front end developer, requirement analyst and tester. He show his best tricks on what works in small and large scale organizations based on his experiences as a Jira expert. Prepare for a provocative and inspiring session where we dive into the 4 design principles for a sustainable, flexible and controlled Jira that works. For real.
  20. View File Designing Jira Workflows We go over transitional and producing workflows, designing issue types and how to divide projects into a scalable solution that also can be used for SAFe. Stockholm AUG Leader Jimi Wikman show the setup he has built based on his experience as a project leader, release manager, designer, front end developer, requirement analyst and tester. He show his best tricks on what works in small and large scale organizations based on his experiences as a Jira expert. Prepare for a provocative and inspiring session where we dive into the 4 design principles for a sustainable, flexible and controlled Jira that works. For real. Submitter ©Jimi Wikman Submitted 04/16/2020 Category Atlassian
  21. Som så många andra älskar jag Jira Software Cloud på min iPhone och jag använder en webbläsare när jag jobbar på min Mac. Det kommer att ändras snart för Atlassian har annonserat på Apple’s Worldwide Developers Conference att Jira Software Cloud får en egen app till Mac senare i år! Förutom det faktum att Jira Software Cloud kommer att dra full nytta av macOS som notifieringar, keyboard shortcuts, spotlight sökningar, drag and drop, toolbars och så vidare, så kommer du även att synka mellan dina olika enheter. Jag ser fram emot att se mer av detta för att se exakt vad fördelarna kommer att bli över att köra den webbaserade varianten. Om du vill få en förhandsnotis när Jira Software Cloud kommer till App Store, då kan du registrera dig på Atlassians sida här.
  22. Automation in Jira have long been requested by the customers and now it is finally here for all Jira Cloud customers. This new feature is actually not new, but it is the popular Automation for Jira app that was purchased by Atlassian in 2019. Not only is this an amazing addition, it is also completely free for all Jira Cloud users. Automation for Jira was purchased by Atlassian back in October 2019 and in March 2020 the automation functionality was made available natively to every single Jira Cloud instance at every tier. In late March the first DevOps triggers was released with the promise of new functionality coming soon. For server users there is still the old app for now. With the new automation feature that is built into Jira Cloud you can now automate a lot of actions. Not only will this free up time for you and your team, it is also super easy to setup with no coding what so ever! This is pretty impressive of course, but when you extend this across other products like Bitbucket and Github, then you get something very nice indeed. I have used the Automation for Jira app before and really liked it's simple, yet powerful features. It is really, really good that this now comes as a standard feature for all Jira Cloud customers.
  23. Automation in Jira have long been requested by the customers and now it is finally here for all Jira Cloud customers. This new feature is actually not new, but it is the popular Automation for Jira app that was purchased by Atlassian in 2019. Not only is this an amazing addition, it is also completely free for all Jira Cloud users. Automation for Jira was purchased by Atlassian back in October 2019 and in March 2020 the automation functionality was made available natively to every single Jira Cloud instance at every tier. In late March the first DevOps triggers was released with the promise of new functionality coming soon. For server users there is still the old app for now. With the new automation feature that is built into Jira Cloud you can now automate a lot of actions. Not only will this free up time for you and your team, it is also super easy to setup with no coding what so ever! This is pretty impressive of course, but when you extend this across other products like Bitbucket and Github, then you get something very nice indeed. I have used the Automation for Jira app before and really liked it's simple, yet powerful features. It is really, really good that this now comes as a standard feature for all Jira Cloud customers. View full blog article
×
×
  • Create New...