Jump to content

Search the Community

Showing results for tags 'jira'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Support
    • Open Forum
  • Professional
    • Management
    • Requirements
    • Development
    • Test
    • Design
  • Interesting
    • Atlassian
    • E-commerce
    • Wordpress
    • Hosting
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Thoughts
  • Destiny 2's Discussions
  • The Journey's Discussions
  • Cinephilia's Topics
  • Cinephilia's Movie Database
  • Diablo 4's Diablo 4 Topics
  • Shadownessence's Topics
  • sensory hyperreactivity's Topics

Calendars

  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Development Events
  • Test Events
  • Design Events
  • Interesting Events
  • E-commerce Events
  • Atlassian Events
  • Destiny 2's Events
  • The Journey's Events
  • Cinephilia's premieres
  • Diablo 4's Diablo 4 Events

Categories

  • Presentations
  • Graphics
  • Personal Files
  • Certificates
  • Shadownessence's Files

Categories

  • Project Manager
  • Jira Expert
  • Requirement Analyst
  • Tester
  • Neurowbdesigner
  • Graphic Design
  • Front End Architect

Categories

  • Personal
    • Movies & TV shows
    • Games
  • Professional
    • Management
    • Requirements
    • Development
    • Testing
    • Design
  • Interesting
    • Atlassian
    • E-Commerce
    • Hosting
    • Wordpress

Categories

  • System Science Program
  • Graphic Design Program
  • Single Courses
  • Certifications

Categories

  • Personligt
    • Humor
    • Spel
  • Allmänt
  • Intressant
    • Prylar
    • Säkerhet
  • Professionellt
    • Kod
    • Design
    • Atlassian
    • Wordpress

Categories

  • Management
  • Development
  • Operations

Blogs

There are no results to display.

There are no results to display.

Categories

  • Personal
    • Humor
    • Music
  • Professional
    • Management
    • Requirements
    • Development
    • Testing
    • Design
  • Interesting
    • Atlassian
    • Wordpress
    • E-commerce
  • Destiny 2's Videos
  • Destiny 2's Streamers
  • The Journey's Videos
  • Cinephilia's Trailers
  • Cinephilia's Full Movies
  • Diablo 4's Diablo 4 Videos

Categories

  • Just for fun
  • TV & Movies
    • Lord of the Rings
    • Star Wars
    • Marvel
  • Atlassian

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

Found 19 results

  1. Version 1.0.0

    0 downloads

    When working at H&M as the Jira expert I issued Certificates of Excellence to the Gods of Jira team. This one was issued to Bharath Kumar Dhanasekaran for his outstanding work as a Jira expert. "For performing above and beyond Awarded for working in a professional way with exceptional dedication that has been above and beyond just being service minded. It is also awarded for a positive attitude that is appreciated by co-workers and clients alike. Finally it is awarded for being passionate and being active in learning new things in Jira."
  2. Optimizely har annonserat ett plugin för Jira Cloud som visar status på Optimisely’s feature flags. Det är ett intressant plugin, men frågan är vem den funktionen är för och hur det ska användas? Jag gillar Optimizely och deras produkter, speciellt för att kunna köra A/B tester på ett enkelt och kraftfullt sätt. När Optimizely presenterar ett plugin till Jira så är det så klart dubbelt bra, men tyvärr verkar pluginet inte göra så mycket och jag är lite fundersam till vem det är som faktiskt ska använda det? Enligt Optimizely så är det utvecklingsteamen som ska komma närmare när man jobbar med att testa features i produktion. Det låter ju toppen, men hur ska det ska bara genom att dra in statusar från Optimizely? Kanske är det bara första steget, för det jag iallafall egentligen vill ha är att kunna koppla olika brancher till feature test direkt i Jira. Det som jag funderar lite på är just vem som den här typen av information är intressant för. Jag vet ju att som utvecklare vill du helst inte gå in i Jira utan sätta upp din IDE så du kan hämta Jira information, skapa brancher och jobba fokuserat. Från ett management perspektiv så är det enklare att ha hela Optimizely informationen tillgängligt Oavsett är det ett intressant plugin och jag är glad att se att vi knyter A/B testning närmare utveckling. Jag ska se om jag kan få en kommentar från Optimizely om deras plugin så vi får höra direkt vad deras vision är för pluginet. Optimizely’s plugin är gratis för Jira Cloud och du kan begära en licens här.
  3. 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.
  4. 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.
    • Multiple Right Answers
    • 10 Questions
    An easy and fun quiz to test your knowledge of Jira from Atlassian.
  5. View this quiz How much do you know about Jira? An easy and fun quiz to test your knowledge of Jira from Atlassian. Submitter ©Jimi Wikman Type Multiple Right Answers Total Questions 10 Category Atlassian Submitted 11/10/2019  
  6. 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 want 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?
  7. View File Jira Icons A few icons for issue types in Jira as presented in: Submitter ©Jimi Wikman Submitted 07/18/2019 Category Graphics  
  8. Atlassian has announced that a free tier for all of the company’s services that didn’t already offer one is coming. Atlassian now also offers discounted cloud pricing for academic institutions and nonprofit organizations. This is great for smaller companies that want to upgrade from the popular Trello platform, which is also owned by Atlassian. Jira Software, Confluence, Jira Service Desk and Jira Core will get free tiers in the coming months. Exactly what the limits will be on these free tiers is yet to be seen, but it is safe to assume that the current 10 user tier that is the entry level will probably be free. In addition to this we will also see an extension of the trial version which is very short today. This allow companies to better evaluate before committing to a purchase. "We’re announcing free plans of Jira Software, Confluence, Jira Service Desk, and Jira Core – available in the coming months. This adds to the existing free offerings already in place for Trello, Bitbucket, and Opsgenie to give teams of all sizes, even small ones, a set of fundamental capabilities for team collaboration." - Reaching new heights in the cloud For me this is great news as it allow many smaller companies to get introduced to Jira. This allow Jira to organically become a foundation of the workflow as the companies grow. This should multiply the use of Jira quite a bit, especially with the new next-gen features that are very similar to Trello. I like this move quite a bit and I look forward to hearing more about this as the new tiers are published. In addition to this they also talk about their Cloud Premium offer and the new discount offer for academic and non-profit organizations.
  9. In the previous articles we have defined what tool to use for what and what issue types we need. New it's time to define the workflows for those issue types. Before we can do that however we should first define what workflows are and how we should use them in Jira. Three types of workflows In short we can narrow down workflows to three types: sequential, state machine and rules driven workflows. Sequential workflow This workflow is usually chart based from one step to the next, always moving forward without ever going back. Each step depends on the completion of the activities on the previous step. You can think of this workflow as a connect the dots system: you have to follow the numbers correctly, one after the other, to complete the big picture. State Machine Workflow This type of workflow can be considered like puzzle solving, in which you’re constantly putting important pieces in place to complete a project. State machine workflow are frequently used when there are creative elements in the process, or products and services that require extra review or input from clients and management. Rules-driven Workflow This workflow is executed based on a sequential workflow with rules that dictate the progress of the workflow. This can be compared to following a blueprint to make one complete structure. Rules driven workflows are very useful when working on a variety of projects with clear goals but varying levels of specifications. We should also define what a workflow is NOT: A workflows is NOT a process - A process is more then just a workflow as it includes data, forms, reports, actors and more. A workflow usually span over multiple processes as we hand over responsibility between different capabilities (requirement, development, test, acceptance). A workflow is NOT a list of unconnected tasks - Unconnected tasks are task management and not a workflow. A workflow is NOT a checklist - Checklists are binary. It's either done or not done. That is not a workflow. A workflow is NOT a state diagram - This is probably the biggest issue I see when people try to design workflows. The idea that you need to track every single state in a workflow comes from a misunderstanding of who we actually build workflows for and what they actually need. "A state machine (panel (a)) performs actions in response to explicit events. In contrast, the flowchart (panel (b)) does not need explicit events but rather transitions from node to node in its graph automatically upon completion of activities." - Wikipedia Who do we build workflows for? In order to understand why state diagrams are not the best choice to design workflows in Jira we should understand who we build workflows for and what purpose they serve. The reason we use Jira is because we want a good way to define and assign work. We also need a way to oversee, or manage, the work. This means that we want a way to track what work we are doing, what the current status is on that work and who is responsible for completing the work at the moment. So for developers and testers we want en easy way to see what is ready to be worked on, what is being worked on and and what have we completed. For managers we need the same, but over the whole chain of responsibility. We also want to connect the work to the need so we can follow up when the need is being fulfilled. So we have two basic need to fulfill: What is ready for me to work on? Are we on track to fulfill the need or do I need to take action? In the previous article we mentioned transitional and producing items when defining what issue types we need. We can match these theories with these two need as well. #1 is producing as we just need to track the actual work in a fetch and release process. For #2 we use transitional as we want to track all areas of responsibility. Based on this we can see that there is no need to see everything that happen in the work we do. We need to see who is doing what and if there are any impediments that could prevent us from completing the need in time. This is why we choose to work with flow charts and not state diagrams. "Design for collaboration, not control" If you feel that you must track every single step in the work, then I suggest you take a look at why you need that. Usually it is because you lack trust in your organization due to poor communication or that someone in the chain of management suffer from an unhealthy need for control. Either way you should fix that outside of Jira as we should design for collaboration, not control. What statuses do we need? So now that we know what types of workflows we have to work with and what the need is we need to fulfill, then it's time to break down what statuses we actually need. We start by defining the different areas of responsibility that we need to track in our workflows. Development Test Acceptance First we start with adding a waiting status in each so we can fulfill the need of knowing what is ready for us to work on. This will also allow us to get statistics on waiting periods to see where we have resource issues. We name them the same to keep a proper naming convention: "Ready for <area of responsibility>". Secondly we add a status for when someone is working on something. Again we can track this for statistics, but most importantly we can quickly see what is being worked on and by whom. We name this the same as well: "In <area of responsibility>. We end the basics with setting a Closed status as the last status. This will allow us to set a resolution and indicate that the development work has been completed and is ready to be deployed. I often see people adding things like resolved or done, but in a workflow you should not have partial closure and there is actually no need for it. We now have the basics for a fetch and release process and we have fulfilled the first need. In order to fulfill the next need we need to add a few additional statuses, but first we should change the starting status. In Jira we have Open as the first status when a new issue is created. This is a bad status as it is not clear what Open really mean and I have seen whole organizations failing due to this misunderstanding. So we will rename this status to New if we can do that for the whole organization. If not, then we create a new status and use that as our first status. In order to track when something is blocked or waiting for something we add a status called Waiting/On Hold. Even though we can use the flag function to visualize this I have found that a dedicated status usually make this far more visible in the boards. We will also add a Reopened status in the event that we need to open a closed status for some reason. This either happen because we close by mistake, but in the event that someone actually revoke a closed issue we want to track that. Adding this is a status allow us to define how we want to handle this situation later. Finally we will add a status mostly used for defect management, but it can be used in any development workflow. That status is Rejected. While this can sound like a very harsh status it's purpose is to revert something back to the reporter for clarification rather than using the Close status and then Reopen. With just these few statuses we can manage both need to see what is ready for me to work on (ready for <area of responsibility>), who is working on what (In <area of responsibility>)and if there are any issues that need attention (waiting/on hold). We can not take any issue type and look at what area of responsibility is involved in fulfilling that task and then map the statuses we have defined to that. All generic workflows will have the same statuses. This makes it very easy to work with boards and no matter what capability you work with you always have only 3 statuses to keep track of: ready for me to work on, I am working on this, ready for someone else. What about release management?! Another common question is how I handle release management since there is no statuses for release. The answer to that is that we do not need that since Jira has that built into the core system in the form or versions. Every development should be closed with at least one version in the Fix Version field to indicate what code package the code is placed in. Every defect should also have an Affect Version that indicate what version of the code the defect was found in. By doing this we can map what code is in what package, but Jira should never be master for this information. This information should come from Bitbucket, or similar code versioning tool. This is also the same for deploys, which we do not manage in Jira at all since that is a completely different process. This comes from Bamboo or similar tools. The idea of managing deploys as a status in Jira quickly become silly as you would have a separate step that happen long after development, test and acceptance has been completed. This task is unconnected to the areas of responsibility. It is not a producing step, just a transportation step that is done not on story level, but on code package level. Like we established above this is not a part of a workflow since it is an unconnected task. We will however keep track of deployment in Confluence, but we will get to that in later articles. Let's build the default workflow Let us take all the theories above and make it real by designing the workflow in Jira and see if it hold up for real work. Requirement & business processes happen outside of this workflow. The expectation is that the beginning of the workflow comes in the form of a clarified need as a story. Even in Agile way of working the story is clear enough to be worked on once put into the ”Ready for Development” status. Once a story is clear enough to be worked on and we have acceptance from Development and Test, then we move the story to the status "Ready for Development". Producing items are created for development and we start working on the issue by transition the store to In Development. Once done we transition the story to Ready for development to complete the fetch and release process. This is repeated in the test and acceptance steps. In the event that we get a defect, then we create a defect sub-task and block the story from completion. We can use this for all development tasks as they all follow the same path. Let's see how we set this up in Jira. Building workflows in Jira In order to build global workflows in Jira you need Admin access to Jira. Go to Jira Settings -> Issues. Here you will find the two sections we need to configure to build a new workflow and to assign it to a project. Under Workflows you will see the current active and inactive workflows. In the top right corner you will see a button with the text "Add Workflow" Click that and you will get a popup to enter a name for the workflow and a description. Once you have added a name and description you will come to the design view. Here you use the "Add Status" to add the statuses we want. We create them with global transitions to make the workflow as open and flexible as possible by checking the box "Allow all statuses to transition to this one". I usually have transitions between rejected and new, as well as for Closed to Reopen, just to make it more clear that the rejection is used in a certain part of the workflow. This way you can't go to rejected or reopened from other statuses than the intended ones. In a proper workforce where the users get education on how to use Jira this is not really needed however so you can skip that if you do not feel it is necessary. Add Workflows to a workflow schema Now we can go to workflow schemes where you find all your active and inactive workflow schemes. in the top right corner you have a button with the text "Add workflow scheme". Click that and in the popup you add the name and description of your scheme. You will then be taken to the screen where you add workflows to the scheme and map it to specific issue types. Click the add workflow button and select the workflow we created earlier. In the next screen you get to select which issue types you want to map to this workflow. Select the ones you like, which should be all of our development issue types and then click finish. Your scheme is now configured with a workflow that is mapped to the issue types you want. You can edit this scheme at any time should you add workflows and/or issue types. 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 Workflows. Here you see your current workflow schema and the workflows attached to it. To change click on "Switch Scheme" and select the new scheme that we created above. Click associate and if needed map statuses on the next screen and wait for all statuses to resolve. Once done you have your new workflow scheme mapped and you can start using your new workflow. We now have workflows setup for our issue types, but we still have a few things to do before they are completely ready to be used. That is to define the screens and custom fields we will use in our setup. That will all be explained in Part 4: Defining Jira Screens & Custom fields that we will look at next.
  10. 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 to 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 wee 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 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 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 - 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 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 Desk This area work with supporting the code that is available in production. This require the ability to manage incoming support requests, identifying resolutions and when needed 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 Desk 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
  11. Version 1.0.0

    3 downloads

    A few icons for issue types in Jira as presented in:
  12. 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 want 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? View full article
  13. When working with Jira I often get several questions over and over again. These are common questions and usually they come from a misunderstanding of what Jira is and/or how it works. This is a list of the most common questions I get and the thought is to answer all of them and then link these questions to those answers. Kind of like a FAQ. How can we set up our Jira project to manage multiple teams? How can we move tasks between projects and still keep track of what need to be done? Should we have one long workflow (business need -> release) or multiple short workflows? How can I work with requirements in Jira? Should you have one or multiple backlogs? What is the difference between Kanban board and Scrum board? What type of board should I use? How can I use Jira to track releases? How can I use Jira as a Test Tool? How can I as a manager get an overview of what is going on in my projects? How can I work with SAFe in Jira? What other common questions do you often hear? Let me know and I will add it here.
  14. A presentation on how to design workflows for Jira.
  15. Quick demo to help you get started with Test Management for Jira Cloud (TM4J). To learn more, visit the documentation:https://www.adaptavist.com/doco/display/TMFJC/Test+Management+for+JIRA+Cloud   To get the app, head over to the Atlassian Marketplace:https://marketplace.atlassian.com/apps/1213259/tm4j-test-management-for-jira?hosting=cloud&tab=overview    
  16. Dennis Struis, Product Owner JIRA, ABN AMRO Rik de Valk, Product Owner, ABN AMRO In 2015, ABN AMRO, one of the largest banks in the Netherlands, rolled out agile across their organization. Within a year and a half, ABN AMRO grew from over 100 to 7000 users, and they are now moving towards using JIRA Software Data Center. This growth greatly increased their system complexity, that included 65 administrators that had created over 65 issue types, 250 statuses, and 400 workflows. In this session, ABN AMRO will share the process of introducing scaled agile to their organization, which includes identifying the impact on usability, gathering metrics, and improving system performance and maintenance. You can also learn about how Portfolio for JIRA is an integral part of scaling agile across an organization and which best practices you can apply to your own journey.
  17. Designing Jira Workflows View File 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 07/18/2019 Category Files  
×
×
  • Create New...