Jira Workflows for Business Teams

1. Introduction: Hi. I'm Rachel, right, Certified Ghira administrator and author of the Jiro Strategy Admin Workbook. I love talking about Jura and best practices, and my goal is to keep you out of the Jiro swamp. And if you're already in the swamp, I'll help dig you out. Earlier today, I removed 28. Unused were close for mature application. How do you end up with that many work flows people aren't even using? How does that happen? Well, at one company, Project Leads were constantly asking for new custom work flows and hopes that they would more accurately reflect thirteen's real life process. And as new work closer built, the old ones were disassociated with their projects and left to rot as inactive to your resource is at another company. This is teams were stuck using the work clothes built for software development teams. Even the computer help desk team had a dev workflow, which didn't fit their support process at all. I'm teaching this class so you can build smart work flows that your business teams will actually use well design work clothes should complement a team's process not dictated. We'll cover the following topics. First will review the different types of work clothes, their limitations and how business work clothes are different from software work flows. I'll show you some samples. You can adapt if it the needs of your company. Next, we'll talk about two commonly confused status is resolved and closed, and I'll share a mistake I've made and seen at other companies After will cover best practices like good naming appropriate use of transition behaviors and the importance of rules and groups, then will discuss planning for a custom workflow. Using a phased approach, we'll interview a business team member to understand their process and think about how to best represent it as a deer workflow. Then we'll build the simple workflow while discussing important concepts like editing tools , drafts, transitions and transition behaviors. Next, we'll talk about using add ons to extend workflow functionality. I'll share some of my favorite plug ins that I just can't live without, and finally I'll share Additional Resource Is and downloads so you can continue learning to build great work clothes. Don't miss the course activity, where you'll design a custom workflow that you can compare with mine. All right, let's get started 2. Workflow Types: This is a vanilla Ajira server. Instance. If you're using your cloud, your view will look a little different. But the concepts are the same. Let's look at the work flows automatically added when I installed Jura and created a sample project. After logging in as an administrator, click the Kharg icon at the top right. Select the Issues link and click the workflow link in the left side bar. This work flows admin page shows, all active work flows assigned to projects and inactive work flows, not in use. The first workflow was automatically created by Gira when I created a project using a template. Gear has templates for business teams and for suffer teams. Let's take a look in the main navigation click projects, then create project. This will let you see the project templates. Choose a project type and click next. This will give you a preview of the default workflow for that type. When you create a new project using a template, you're automatically creates the default workflow and creates any needed statuses. Let's explore the default work flow templates. Dear Server and your cloud both come with templates to help you get started building new projects. These templates include all the needed project elements, including a workflow, and were close scheme. Dear also comes with two additional work clothes, one called Ghira read only system workflow and one called Classic Default workflow. You could see in the screenshot that the read only one can't be edited. Let's take a closer look at it. Here's the read only workflow in diagram mode. There are five statuses open in progress, resolved, closed and reopened. Now here's that same workflow in text mode. Text mode shows the transitions between statuses. For example, in the open status, you can click the Start Progress Transition to move to the in progress status. You can click the resolve issue transition to skip to the results status. Or you can click the close issue transition. Just give all the way to the final close status. We'll talk more about transitions later. This workflow was built for software teams. It also restricts who can resolve in close issues. You'll want to use a different type of workflow for business teams. Before I became a jury administrator, I was a Web developer using Jura to track software tasks. I'm very familiar with the software development life cycle. No matter what your development process looks like, software work flows tend to look fairly similar to each other. In general, it goes like this. You receive a request, review the requirements, write the code, test the code and deploy the code Business. Work flows, however, tend to be very different, depending on the team. On the type of work to accomplish. Let's address some example Differences. Business were close sometimes require extra steps to handle things like approvals, research, analysis and dependencies from other parties. Sometimes the workflow is expected to move forwards and backwards multiple times. Ah, purchase negotiation is one example. A vendor might propose a cost, and your company may submit a counterproposal until a final cost is agreed upon. And this could last multiple rounds. Also, ah, business workflow might be conditional on other factors. For example, the Finance Department might have a specific process for paying a vendor invoice but an abbreviated process for reimbursing an employee. The end result is the same. Everyone gets paid, but the initial steps needed may vary based on the situation. The business workflow needs a support all of these possibilities, but in the simplest way possible. Let's look at some business workflow examples. This is a simple legal workflow built into your cloud. In this example, the legal team receives a request to sign a contract. They review the contract, sign it and closed the issue easy. This next workflow shows a sample process for managing a tangible asset like a computer. In this example, a user requests a new computer by creating a new issue. Once the request is approved, the machine is ordered. The order goes through the purchase receipt and configuration process. When the user receives the new computer, the record for the old computer is manually updated to indicate it's been retired. As you can see, you can use the default work clothes, the project template, work clothes or you can create your own custom one from scratch. You can also import sample work flows from the Atlassian marketplace at marketplace that at last CNN dot com. Next, we'll talk about a common mistake regarding too confusing default status is 3. Resolved ≠ Closed: you can see in the screenshot that the default workflow contains both the resolved and closed statuses for quite some time. I didn't understand the difference between the two, and users didn't understand the difference either. This led to issues being considered done in either status. There was no way to report the total work done without manually adding counts from the two statuses together and issues languished in the resolve status forever. I was gonna leave this mistake out, but I just so another company do the exact same thing they were using close to indicate Issues that they didn't do anything for and resolved indicate issues where they did make a fix. And you and I know a resolution Value is the best way to explain how or why something is closed, not a status. So instead, there should only be one status where it's clear to everyone that no additional effort is needed and the standard close status or the business project friendly, done status is sufficient. No need toe ADM. Or status is that mean closed? And if you're going to use the resolve status, teach your users the difference between it and closed at your company and if for some reason you cannot get users to distinguish between the two, rename it or stop using it. 4. Do's and Don'ts: in this lesson, we'll talk about good things to do when creating your own work clothes and also what not to dio. Let's start with the dues. Naming is very important. Injera smart naming of work flows, statuses and transitions. Insure concepts are clear to your users, and things are easy to find for your administrators. You should name your workflow to describe the type of life cycle process it supports, not the project that uses it. So, for example, task lifecycle or on boarding is better than HR workflow. You want to create work flows that are shareable, not one workflow particular project. A status name should be short and reflect a current state in time. Long, multi word names are harder to query for and may be truncated on certain screens. Good status names immediately tell user what is occurring and where they are in the process . Some examples are pending. Review in review or awaiting review. Now transition names should be short as well and reflect an action taken. Good transition names immediately tell user what action to perform to progress an issue, for example, for an issue in pending review status. A good transition name would be review complete now. Bad transition names confused the user about how to move forward. A bad example is the word review. A transition button should signify the start or end of inaction, but the word review is ambiguous. If a user clicks review, does that mean they should start a review? Or that the review has already occurred? I don't know, and your users won't know either. Have you ever worked on a project that didn't go as planned? Have you ever had to start a task over? We shared a factor. These occurrences into your workflow gift users options to abandon or stop progress on an issue at appropriate times. For example, if a request is no longer needed, give users the ability to jump all the way to the final close status. Don't make them click through every step in the workflow just to close an issue. Give users appropriate options to fix improperly transition issues, too, for example, include a reopen transition in the final status to fix issues that were accidentally or improperly closed. Next used transition restrictions sparingly. Do you really need to restrict who can do what Gear records who clicked? What transition went. So in most cases, this is enough of an audit trail. No need to make it more complicated. But if you really do need to restrict inaction, always use project rolls or dear groups in the screenshot example. This transition can only be clipped by a jeer application, admin or administrators in the project. Using roles and groups makes your workflow more maintainable in the future. Avoids specifying names of individual users in transition behaviors and, most importantly, in the beginning, keep work flows. A simple it's possible until you have uncovered a deficiency or process step that needs special attention. Now let's talk about what not to dio. Don't use more statuses or transitions than are actually needed. You only want to add a workflow step for statuses that will be queried or reported on. Not every little thing to do needs a status in the workflow. Don't use the clothes status before an issue is in its final state Clothes should indicate no remaining work is needed. Also don't create duplicates. Status is that also mean closed, the default closed or the business friendly. Done status is just fine. You don't also need to create a completed status, don't create statuses like abandoned or rejected. Instead, use the resolution field to indicate the how or why an issue is in the close to status. Don't create temporary or dead statuses where issues are likely to sit for an indefinite amount of time. One example I see often is the on hold status. Now. A status like this is only useful if someone regularly reviews issues in this state, don't create alter specific status names or use the wrong tents. For example, don't use pending review by marketing or pending review by John. These are two specific and make work flows hard to maintain and share between projects. Another bad example is a status name reviewed. Award in past tense is a dead end, and it doesn't tell the user what needs to happen next. Finally, avoid creating illogical work clothes. Consider the example pictured at one company, their first status was in progress. Now this communicates to the reporter that the minute they're issue is created, someone is working on it. And of course, that wasn't really true. Normally, issues need to be triaged, prioritized, approved or even reviewed for understanding first. Instead, the first status should be open to do or something similar. The first status should signify that the issue was received, but no action has been taken yet. Please join me for the next lesson, which is all about custom workflow planning. We'll interview a business team member so we can understand their process and think about the best ways to represent it injera. 5. Custom Workflow Planning: Let's talk about the planning you should do before you create a custom workflow in the cheer application. That's right. Log out of Jura because building a custom workflow should always start on paper. Now it's certainly possible to capture every little step in your work process and build that into a complex and long dear workflow. An alternative, however, is a phased approach. Simply break your process into faces that represent a collection of smaller steps. The phases represent key decision points. An issue can't be moved to another phase until all the requirements of that phase have been satisfied. That way, each phase represents a status injera, and all the small steps in a phase don't need to also be statuses. For example, imagine your company assigning a partnership agreement with another company. The process requires a review of a contract signed by both parties with potential edits before final execution. It's a predictable process, requiring a short, workflow like open in review, an execution and closed. Even though it's a simple workflow, the legal team is doing many things in the background that don't need to be reflected in the workflow. For example, in the in review phase. The legal team is reviewing the contract, researching legal topics, communicating with internal teams and negotiating terms with the external company. And here's a tip. A generically named status like in review is better than a legal specific name, like in contract review. This way, other dear projects can use the generic status regardless of what type of thing needs review. You want to share assets and schemes between projects as much as possible. Okay, back to the workflow. In the in execution status, the CEO is finding his favorite signing pen. Both companies are treating paperwork, and your legal team is entering the final documents into their contracts. Database. So what do you think? Is it useful to create a status for every single step that occurs in the contracts process ? Do you need to track how many times the contract was modified during the review process? Do you need to track which parties have signed the agreement so far? If the answer is no, a phased approach may be more useful. Now. If you do need to track signatures, a custom field might be smarter than a status, but only create that custom field. If your gonna report on that piece of information and one more tip. If you're not going to query for all issues in a certain status, that's a clue that the status may not be necessary or useful before creating a new custom workflow. Have a team member explained their real life process to you. This is Chris, the owner of a business strategy company, and he'd like to start using Jura to track his consulting process. I Chris, tell me more about your process. I so are consulting. Process basically works like this. Start off with the search for candidates will try to identify the ideal clients that we'd like to work with. We acquire a lead through various lead generation methods. Do a little bit of company research prior to meeting with Candidate Book of Meeting. We'll go through some fact finding template in a performance checklist with the candidate and then, after the meeting, will develop a solution. Plan or re sources that are best used by the candidate will propose a solution as to how best a consultant can help them in their company and if we work with them on an ongoing monthly basis. Weekly quarterly, semiannual and annual meeting structures that will follow always moving towards quarterly in long term goals. Thanks, Chris. I'll be back in touch with the draft workflow. 6. Custom Workflow Process: Let's use the information we collected in the previous interview to represent the process as a juror. Workflow first, right out the process in words that's can uncover additional needs you may have neglected to consider second, split the process narrative. Ontological phases to determine the status is identify the steps or high level phases and issue must go through in its life cycle. In the example, I split the process into four phases and given each a short status name, open planning proposal and active, we also need a close status for when elite becomes inactive. Next draw. The status is in a flow chart. In the example, elite is acquired and own creation is in the open. Status. Research and meetings occur in the planning status solutions, air determined and pitched in the proposal status. If the proposal is accepted, the issue moves to the active status were all ongoing. Consulting occurs when consulting is complete. The issue moves to the final close status. Next, determine the forward transitions and add them to the flow chart and the example. Elite is acquired and on creation is in the open status. The user clicks the start planning transition button to move to the planning status were all research and meetings occur. The user clicks the START proposal button to determine solutions and pitch them to the customer. If the proposal is accepted, the user clicks the start consultant button to move to the active status where all ongoing consultation occurs. When consulting is complete, the user clicks the close button to move to the final close status after determined the needed backwards and alternate transitions. In this example, elite is acquired and on creation is in the open status. The user clicks the start planning transition button to move to the planning status. If no planning's needed, the user clicks skip to proposal to skip to the proposal status in the planning status, a user clicks start proposal to move floor to the proposal status or clicks back to open to move backwards to the open status. In the proposal status, the user clicks start consulting if the proposal is accepted. If the proposal is declined, the user clicks the close button to move to the final close status. In the active status, the user clicks the close button when consulting is complete and in the close status a user clicks the reopened button to reopen the issue. I've noticed that the clothes transition is global, shown with an asterisk. Finally, determine and document the needed transition behaviors. After we've determined everything needed for a custom workflow, it's time to log into dear as an administrator and build it first, only to create any new statuses. Our workflow needs three planning proposal on active, be open and closed. Statuses already exist at new statuses sparingly and Onley when the existing statuses can't be used. Next, I'll create a new workflow, all name. It leaves for the process it supports. I'll use the Description field to record the juror request I d for this customization. That way I can reference requirements and implementation notes later. I'll add all the needed steps and link them to statuses. After I had all the needed forward, backward skip and global transitions, - I'll need to enter diagram mode toe Add the global close transition. As you can see, a global close transition was added to every step. I don't like the default name of Closed. It's all at it to re close instead. Then I'll associate this action with the transition screen. Now I'm consulting my planning documentation to see what other transition behaviors to add here. I'm adding a new post function and modifying an existing one, and that's it. Our customer flow is built on ready for testing. Stick around for the next lesson to learn more about the workflow concepts in the previous demo. 7. Workflow Concepts: In this lesson, we'll talk about important concepts that apply to any type of workflow. But first, a tip. If you're already a certified dear administrator, you can extend your certification by taking the A C B 1 10 advanced zero work clothes exam used the info in this lesson as additional study material. There are two views for creating and editing work. Flows on the Left is a workflow shown in diagram mode and on the right is the same workflow in text mode. Each mode has its own pros and cons. Diagram mode is the simplest and easiest view for your users. This mode includes a workflow designer, which lets you add a status or transition, drag a status or transition around visually, edit transition properties and behaviors, and add global transitions. Ah, global transition allows any status to transition to a different status. For example, I often create a global status called close, so an issue conscripts straight to the closed status from anywhere in the workflow. Now you can Onley create global transitions in diagram mode. Tex mode is considered more advanced. However, you could still edit statuses in transitions. Plus, you can work directly with the steps. For example, if I wanted the workflow to populate a field on the create action, I can do that by clicking the step. Name steps are only visible in text mode. You know, I really prefer text mode. I think the transitions are much easier to understand when shown in table format once the workflow was created. There are different states to be aware off. They are active. Draft an inactive. An active workflow is currently used by one or more projects. You can't delete an active workflow to delete. You must make it inactive by reassigning any projects using it. When you try to edit an active workflow, a draft is created that way. There's no impact to a projects issues until the draft is published and when you publish gear will help you migrate existing issues to new statuses if needed. The screenshot shows I'm editing a draft of an active workflow. There are some limitations to editing drafts, though First you can't change the work flows name. You can edit the work flows description, however, also, you can't remove a status. You can set your transitions to point to a different status, however, so that means the status is still there, but an issue won't go through it during the workflow. And finally, you can't add outgoing transitions to a status with no existing outgoing transitions and now some tips. If you're planning to make major workflow adjustments, make a copy of the workflow and make changes to the copy instead. Then you'll have no editing limitations. Also, build or modify your workflow in a test environment first, then, after you've verified all your changes, export the workflow and import it into your production environment. This prevents users getting spammed with notifications while you're testing. Alternatively, you could temporarily assign your workflow to a production project built specifically for workflow testing. And finally, changing or renaming a status will break user filters and board map ings. This will impact user dashboards, boards and reports. The last state is inactive. Inactive work flows aren't in use by any projects and therefore have no limitations. You can edit them in any way or delete them next. I'd like to tell you about two incorrect workflow assumptions. I made the screenshot shows an asset management workflow in diagram or visual mode, so I once used the visual moto edit a status. I thought this change was on Lee going to apply to that one workflow, but instead I changed the name of the entire status in all of the era. So users alerted me to the problem because I had broken all of their filters and work flows . Secondly, I thought, Gee, era treated transitions to the close status. Specially, I thought, There's gotta be logic in the background, making close the final step in a workflow clothes must be special. I thought a status change would automatically trigger that issue. Updated line item. But no, I was wrong. So instead of making these two workflow mistakes, don't change status names in visual mode unless you're really trying to change them in all of Jura. And then Jura has no special regard for that status. Name closed. It's just a status like any other. So when you create a new workflow transition, a default post function is automatically added. But as you can see, it reads, fire a generic event that can be processed by the listeners. You want to change that to an issue closed event. If you want a notification sent for that action now let's discuss transitions, which are the buttons users click to move between. Status is, users often confuse the standard issue buttons with the workflow transition buttons. This screenshot shows both because workflow transition buttons differ between projects and also issue types. Users aren't sure which button to click, and sometimes users mistakenly think that the first workflow transition button is the issues current status. Sometimes users don't know that there could be extra transition options under the workflow button. Hopefully, a little bit of user education could help avoid these issues. Don't name a workflow transition button with the same name as a standard issue button. Otherwise, you'll have to assign buttons or to comment buttons, which will really confuse your users. Now let's talk about transition types. They are forward, backward, global, skip and administrative. Let's recall our sample legal workflow of open in review in execution and closed. A former transition is just like it sounds. It moves an issue forward in the workflow. I like to name afford transition, so users have an idea of what the next statuses, for example, Ah, good transition name between open and in review would be start progress or ready for review a backward transition moves an issue to a previous status in the work flub. I like to make this movement clear in the transitions name, for example, to move backwards from the interview to open status. I've named the transition back to open. We talked about global transitions earlier. Use these to allow all statuses to transition to a different status and the simple workflow I could create one global transition. Teoh easily close an issue from anywhere in the workflow. Without this feature, I need to create three individual transitions to achieve the same effect. Now you don't just have to move forward or backward in a workflow. You can also skip around if needed in the sample. I could create a transition to move from the open status directly to in execution. I'd like to make this moment clear in the transitions name as well. For example, I've named the button skipped execution. Finally, you can also create transitions just for fixes or administrative use. There are a 1,000,000 possibilities, but here's one example. You could create a transition that updates a custom field. Then you could use bulk tools to make the same update. Too many issues at once. The transition doesn't even need to change the status Now. If you don't want general users clicking these special transitions, you can hide them with the transition behavior. Speaking of transition behaviors, there are four types. Triggers conditions, validators and post functions. Triggers help Keep your issue data in sync with development tools like fisheye and bit bucket. We won't cover triggers in this course, however, a condition checks whether a transition could be performed by user. For example, use a condition to Onley. Allow the reporter or current assign me to see a button. If a condition is false, the transition button is hidden. Miss Me is a user may encounter an issue with no transition buttons available to them. A validator checks whether certain data exists before the transition occurs. If a validator is true, the transition succeeds in a validator is false. The issue does not transition until the data is updated or returns true. For example, use a validator to make sure required field has a value or that a user has a certain permission. Ah, post function is an additional rule or action that occurs after the transition. Thes only execute if the transition is successful. For example, use a post function toe automatically assign an issue to the reporter when moving to a more info needed type of status, or use a post function to clear the resolution field. When it issue is reopened, you could say that post function label number one in the screen shot workflow behaviors are just the beginning. You can further extend your capabilities with plug ins and add ons. Join me in the next section for some personal recommendations. 8. Add-ons & Plugins: many add ons provide additional workflow functions. Some add ons even come pre installed in cloud environments. You may need to enable them from your manage add ons. Admin page Visit Marketplace that at last san dot com to explore the possibilities. Most plug ins come with a free trial that you can install from admin. Add ons find new add ons. There are so many great plug ins here, so of my favorites, I use Script Runner for Ajira to maintain here as a whole script transition behaviors and modified behaviors of fields I use create on transition and update on transition to reduce manual work, like creating the same child tasks or completing the same field over and over again. I used your miscellaneous workflow extensions to help with things users sometimes forget. Like to start progress on apparent issue when the child issue starts progress, or to make sure all child issues are closed before parent issue is closed. I used to jeer toolkit plug in to show custom user instruction messages on transition screens, and finally I used the sweet utilities for Jiro Plug in to restrict transitions to multiple groups and rolls require a comment on transition and update custom fields. There are so many possibilities. I encourage you to test out the standard workflow behaviors, and the additional behavior is provided by add ons. 9. Resources: I hope you enjoyed this work clothes course as much as I enjoyed building it by now, you should have a good understanding of the different workflow types. How to design and build customer close, common mistakes to avoid and how to enhance work close with behaviors and add ons. Next test what you learned with the included activity. You'll design and build a custom workflow based on a description of a business teams process. You can also take the course quiz. Finally, you can download additional materials and continue the conversation using the link shown. Remember, it's always best to start out with a simple workflow and build more as it's needed. Don't over complicate your workflow with steps in status is you don't really need your gear . Application will be cleaner and your end users will thank you for it. I'm Rachel, right. Author of the Jiro Strategy Admin Workbook. Happy workflow Building