Team Workflows in JIRA | Dan LeFebvre | Skillshare

Team Workflows in JIRA

Dan LeFebvre

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
17 Lessons (1h 29m)
    • 1. Course introduction

      1:43
    • 2. Our first step to updating Jira

      4:05
    • 3. Our real-world scenario

      5:08
    • 4. Overview of our solution

      4:47
    • 5. Creating a new agile board

      4:07
    • 6. Adjusting our board's filter

      6:44
    • 7. Adding new columns

      2:27
    • 8. Working without a simplified workflow

      10:59
    • 9. Building the QA team board

      6:52
    • 10. Creating a new status

      4:03
    • 11. Adding statuses to our QA board

      9:59
    • 12. Adjusting the 'Done' statuses

      7:39
    • 13. Understanding our team setup

      2:44
    • 14. Auto-assigning issues to our QA team

      7:31
    • 15. Auto-assigning issues back to our dev team

      5:05
    • 16. Optional: Adding color cards

      4:17
    • 17. Course conclusion and where to go from here

      1:17

About This Class

Just updated in June 2019!

This Team workflows in JIRA course is intended to give you some tips, tricks and techniques you can use right away to work better in JIRA. We'll use a project-based approach to build a workflow that allows a dev team to send issues to a QA team and then have the QA team send them back through JIRA's agile boards.

Along the way, we'll learn about many of JIRA's features including agile boards, filters, permissions, workflows, schemes, and many more.

This course is perfect for JIRA administrators and anyone who's familiar with JIRA but wants to learn some new tips and tricks for building team workflows in JIRA.

Transcripts

1. Course introduction: hello and welcome to this course covering teamwork flows. Injera in this course will take a practical project based approach toe learning some of the techniques for teams injera. Now the example will be using is made up. But that's only because I can't publicly show my company's Jura installation. However, the workflow that we're going to create is a very real one that I've had managers asked me to set up for their teams inside of gear up. Our goal for this course is to set up a workflow. So the Dev team in our company contract bugs, then send them to the Q A team for review. Then from the Q A team's perspective. Our workflow will let them choose between either approving them and closing the bugs or marking them as needing MAWR fixes and sending them back to the Dev team. Along the way will dive into customizing jurors, boards, filters and work flows. We'll learn how we can start to create new features and customise existing ones to achieve what we need. Now this course is not a beginner level. Course with that in mind will be moving pretty quickly, So if you're not familiar with Ghira at all. I would recommend watching my understanding Jiro course first to get familiar with some of the basic terms and concepts injera. But if you're already familiar with jeers, basic terms and concepts than you're ready to dive in, so join me as we learn how to build teamwork flows injera. 2. Our first step to updating Jira: in this video will take a couple minutes to get a better understanding of the first step toe updating Europe. And it doesn't start by logging into Jura either. Now, before even sitting down to the computer to make any updates, I would always recommend taking the time to figure out exactly what we're going to do first . Now the reason for that is because any change that we make is going to disrupt somebody's productivity. And that's something I always like to keep in mind as Ajira administrator is that those changes that we make will disrupt someone's productivity. So with that in mind, we want to make sure that we take the time before doing anything to ensure the changes that we make will actually be worth it in the end. Now, for example, in my own experience, there's been a lot of times where team leaders will come to me asking that I change something in Jura for them when the reality is that it's just that their team didn't fully understand how Jiro works or how to use it. There's nothing wrong with that, but if that's the case, that instead of changing the workflow, it's best to schedule a time to sit down with their team and share the basics of Jiro with them. And, of course, I always like to leave them with access to some of my courses so they can check them out on their own time afterward. So here is the process that I use before making any changes in Jura. The first thing is to schedule a quick meeting with the team, lead or team leaders, depending on what it is that you're going to be doing. It doesn't have to be. Ah, long meeting could be about 15 minutes, but of course, that will change depending on your specific scenario. The goal of this meeting, though, is for you to capture all of the challenges that their team has inside of Europe. You might not be able to solve all of them, but by airing their difficulties, you'll be able to get a good sense of not only what they need help with, but also the priority for those challenges. Now, after your meeting with the team, lead head back to your desk and take some time to figure out the steps you need to get done in order to help solve those challenges, map it all out and compare it to the challenges from your meeting notes so that you'll be able to make sure you can tackle as many of those as you can. Of course, I don't mean to imply that all of this has to be done on the same day. But depending on the timeline is certainly can be. That's up to you after you have an idea for how you can modify Jura to meet your teams. Need chat with a team leader again to propose those changes. Explain how it will help solve those challenges and give them an idea for what the new workflow will look like for their team. Now, as with everything, of course, feel free to make tweaks and changes as you need to and remember, always stay in contact with the team lead so they know what's going on. Changing Jura work flows should never come as a surprise, and you definitely don't want to change something while their team is on a tight deadline. So constant communication is key to the whole process. Okay, so in this video we learned about the first step toe updating Jura and really centers around figuring out a good plan for your team. First, of course, if you are the team leader than you could make those decisions a little bit better. But in my case, the workflow we're going to be building in this course wasn't based on my team. It came from the manager of a different team who had some challenges. He wanted my help solving injera. So let's move on to our next video, where we'll learn how that meeting went so we can get a plan in place for what we're going to do in this course. 3. Our real-world scenario: In our last video, we learned about the first step by chatting with the team leader to put a plan in place for what changes to make before ever diving into gear up. Now, as I mentioned in the last video, this is all based on a real world scenario. Of course, the names and specifics air changed, but the workflow itself is the same. So that's why in this video will understand the example that we're gonna use in this course that came out of the meeting with our team leader. So when I sat down with the team leader to figure out what challenges he was having with his team, I took a bunch of notes. I'll save you from having to try to read my whole hand writing of his actual notes. But here's the challenges that he explained to me. The team leader wanted to be able to track bugs across multiple teams using a single issue . So that way, all the Commons and history can be in a single place now to get some context, this workflow will affect two different teams Now, in my case, they both happen to be under the same team leader. But of course, your company might be different. One of the teams was the development team. They're tasked with squashing the bugs, and while hopefully they get everything fixed the first time around, having a second set of eyes is always a good thing. So that's where the other team comes into play. And that is the Q A team now the Q A team is in charge of testing pretty much everything that comes out of the deaf team before it's released. Since this particular workflow is for bugs, the challenge here was to track bugs as their fixed before they're released. Now, one thing I like to do in my meetings like this with the team leader is toe. Ask them what their ideal workflow is. Think of that just like any feature request for your software or service. Of course, you can't always guarantee it will be exactly what they want. After all, every piece of software has limitations, and juror is no exception there. But if we can get as close as we can to their ideal workflow, then that would be the best case scenario. So when I pose this question to him, this is how he described what he would like to see. It really starts with the bug being reported and assigned to someone on the Dev team didn't really matter who it was assigned to at this point. That's something that they would decide in their sprints Now. No two bugs are the same, of course, but in the end, hopefully it should be the same and that by that I mean that the bug gets squashed by the Dev team and once that is done, then the Dev team should be able to send that bug over to the Q A team toe, have it show up on their board. And this board is something that the team leader wanted to be completely different, not the same board as the Dev Teams board. So at this point in my notes, I jotted down that will need to create at least two boards and if you recall, one of those is going to have to be a scrum board to support sprints because the team leader mentioned sprints. But then he continued, explaining that there's basically two outcomes for the Q A team testing bugs, either it can pass and the Q. A team, uh, says that the bug is good to go, and if that's the case, then they can complete the bug and closed the issue. They don't want it to show up on the Debs teams board anymore. Or the other potential scenario could be that the Q A team finds something that the Dev team needs to look at now. If that's the case, they need toe have the ability to send it back to the Dev team, and then it needs to pop back up on the Dev teams board. And at this point, we probably wanted to disappear from the Q A team's board, so they don't have to worry about it anymore. But of course, then this whole workflow repeat. So if the Dev team does find something, they can send it back to the Q a team to verify that those changes were made and so on and so forth now, before wrapping up the meaning with the team leader. I always like to ask if there's any last thoughts that they have, and in this case he couldn't think of any. But there is one thing that I think is important to point out, and this was just something that I happen to know. It wasn't something the team leader actually mentioned to me. But I knew this because I worked with The Dev team closely for a while. And that is simply that that this particular Dev team likes to do pair programming. So instead of one programmer tackling a bug, it might be a couple different programmers. Okay, so that just about wrapped up the meeting with the team lead. I told him I'd figure out a solution and let me know how we could tackle those challenges. And as you can probably guess, that solution is what we'll be covering in this course. So let's move on to our next video, where we'll uncover the solutions we came up with for the team leader's challenges. 4. Overview of our solution: In our last video, we walked through the real world scenario that I was asked to create injera from a team leader wanting to track bugs across the Dev and Q A teams. Now, after meeting with him, I came up with a solution to as many of those challenges as I could and in this video will take just a few more minutes before jumping into Jura to get an overview of the solution we agreed upon. So let's start with the boards Are two teams need to separate boards toe work from on a daily basis? The DEV team uses Sprint's so they will need a scrum board. On the other hand, the Q A team just needs to track things. They don't use sprints, so we'll just create a can band board for them now. We also want to simplify the issues on the board so that the Q A team doesn't need to see The Dev teams issues. They only need to see the issues that are assigned to them, and the same goes for the deaf team. Once it's passed over to the Q A team we wanted to disappear from the Dev teams board So here's what that will look like for our Dev teams board. They'll be able to drag a bug onto their sprint, then the work on it throughout the Sprint. And once it's done, they'll drag it to a column on their agile board, and that will trigger it to be sent to Q A. When it does this, it will disappear from the Dev teams board and then on the Q A team's board. They'll have a calm where that bug will show up as soon as the Dev team drags that bug over . After they've run their tests, the Q A team will be able to drag it to the done column and pick between either sending it back to the Dev teams board if it needs more fixes or just completing the issue overall. And then it disappears from both boards Now. There was a challenge that I mentioned in the last video, and that was really for my particular scenario that The Dev team practices pair programming and this is a challenge because Jura has a limitation of only being able tohave. One assign e per issue. You can reassign that issue to whomever you want as many times as you want, of course, but it will only be assigned toe one person at a time. So just to verify this wasn't something that they were going to change. When I was building this out for the team leader, I reached out to it last in support to double check. They've got a great team, and I would encourage you to use their support when you have questions about work flows. In this case, at last you told me that basically, they purposely will only allow one issue toe. Have one assign it, because that's how agile methodology works. One person responsible for one issue. So my suggestion to the team leader was to assign a point of contact in the pair programming teams who is responsible for Jiro issued. It doesn't really matter who it is as far a seniority, but that makes it easy for one person to know they are in charge of updating the jeer aboard, and those issues will be assigned to that one person. Now, as an added bonus to this, this kind of a work around to that challenge. In this case, the team leader really liked this idea because he didn't wanna have to track down multiple people for every project. And this helped give him only one person responsible for each issue. So even though they worked on tackling bugs in pairs, he'd only have one point of contact for each issue. Now, if you do something like this, even though Jared doesn't let you assign a single issue to multiple people at once, as I mentioned earlier, you can reassign it to whomever is doing the programming at that time so you could swap the tickets, assign me to whomever has control of the keyboard for those pair programming sessions. The key here is just to in our solution, was toe have a point of contact, so we know that it's always going to be assigned to one person, and then they can choose who it gets assigned to and send it back and forth. Or you can use sub test your even create multiple issues to track things better for your team. Okay, so that is a look at the solutions that will be tackling throughout this course, and now it's time to hop into Jura and get started. So when you're ready, I'll see you in the next video where we will start by creating our Dev Teams board first 5. Creating a new agile board: in this video will dive into gear up and start building our teams workflow by creating an agile board for our Dev team. Now, before we begin, I want to point out that in the real world you might already have a board created. For example, if you come up here to create a project and create a new project inside of Jura than these templates here by default will tell Jared to create both the project and the board at the same time. So if you already have the board ready to go, that's fine. You can skip this video if that's the case, but in our case, the project exists already. But it was created as a can band board and we need to create a scrum board so that are deaf team can have sprints. So let's walk through the process of doing that. So I'm gonna click back out of here cause I don't want to create a new project. I want to create a new board and there's a couple different places we can go to do that. One of those is to come into the Actual Dev team here. So this is the project we're gonna be working in. So if I open up this project over here on the left hand side will see our boards. So this board that we see right here is the Can Van board that was created when I selected the Can Band templates creating this project. So this can ban board was created, but we want to create a scrum board inside of this project. So there are two places we can go to do this one we can just click on create board right here, or we can view all of our boards across all of our projects and then up in the top right hand side. There's this button to create a board. Once we do that, were given the option of you who want to create a scrum board or we want to create a can band board. And as we mentioned earlier, we want to create a scrum board. So let's do that. And we wanted to be from an existing project. I do not want to create a brand new project with this. I want to create the board from an existing project. So click next and let's give this a name So this will be our death team, Sprint's board and we want it to be in, Ah, have the dev team. So this is going to basically create a filter that will show all of the issues from that ah project and we need to pick the location now. This changed recently injuries. So if you're using an older version of gear, if you're used to Jura from past years, it wasn't necessarily this way. But the way that it works now is that boards have toe live inside of a project in Europe. That does not mean that you can Onley have issues from that one project displaying on that board. It just means that that is where the project lives. And this part right here is important as well. This little bit of text right here. It has to be ah software project, and that's because it to scrum board. So because it's a scrum board, Jere is telling us it has to be a software project. Now it's outside the scope of this course, but real quickly it's worth pointing out that as of this recording, you cannot change a project type injury. Europe that is something you pick when you set it up. So if you're using Juris software and you created a project as not a software type, you will not be able to put your board inside of that project. But if you do need to work around that, you can create a new project and then both move everything into that new project. If that workflow is something you like to see in its own course, let me know. But for now, let's just continue on with our task at hand. So with our board created, we have it ready to go. Let's move on to the next video, where we will start looking at customizing some of the board settings. 6. Adjusting our board's filter: In our last video, we created a new scrum board. Four are Dev Team in this video, we're going to add some customization to that board. All right, so we're here on the backlog, which is where we were spit out when we created this board. And, of course, we can navigate the board, see the actual board itself by coming toe active sprints. But we don't have any active sprints because we just created this. So let's hop into the board settings and we can get there by coming up to the top right hand side to the three little dots and going to board settings now in here. There's a few key things that I want to point out that a relevant for the project that we're going to be working on today, and the 1st 1 here has to do with the saved filter. This is the filter that's going to determine what displays on the board. So if at any time you do not see issues showing up on your board, if you say if you already had a board that you had created and you want to pull in issues from another project or you wanna pull in another issue, type or whatever that might be. You're going to need to edit this filter query. And if we pull this up in a new tab, weaken See, these are all of the issues that are going to show up on this board. And if we want to change the project, we could add in other issues if you wanted to, from different projects, other issue types, whatever we want to do, just change this query and that will determine what issues show up on your board. So, as I mentioned in the last video, it doesn't matter where your board lives. You can have issues with more from multiple projects showing up on your board by changing this query. And, of course, if you do change it, make sure you actually save that. But for our needs today, I'm not going to need to change this. I just want the issues from this particular project here. So the next thing I want to customize for this is I want Teoh make the epics swim lanes, and so that's going to help just kind of display and see them a little bit easier on our board. So to visualize this, let's come into our backlog here. I'm gonna open this up in a new tab so that we can bounce back and forth between the settings and the actual board itself. And let's just create a test sprint. And this is going to be something that I want to, uh, use just to visualize this and be able to see what the changes are that we're going to be making. So I'm gonna call this. This is my test sprint. There we go. And let's just take all of these issues and let's drag them onto the sprint. Okay, So with all of these on the sprint, if we start the sprint that we go, that's fine. Just leave it at the default. So now we can see the issues on the board kind of like what it would look like for our team when we're actually walking when they're actually doing it on a day to day basis. And when I'm setting things up for a team, I like to be able to visualize things exactly as they will. So that way I can make sure to fix any of the bugs there issues that they might come across . So by changing the view here, So right now these are the epics, and I would like to change that to display in these swim lanes. So I'm gonna come in here to swim lanes and Basit on Epix. And so now if I refresh the board, you can see that the epics here are swim lanes, and these are nice and organized by those. Okay, that's pretty much what the swim lanes do. It's just a nice little way of adding some customization for a team leader. And of course, if if we show this to them, he proposed this change to them and they don't like that, then we can come in and take that out if we want to. Now, one other key thing since our workflow today is really based around bugs and the bugs issue type in particular, you can see this is a bug Here. Um, this is a bug here. These are stories. If we hover over them, you can see the difference between those issue types. There's really no easy way to see what the bugs are versus the, uh, versus the stories, right? So it's it's it's difficult. I have to scroll way down, and I have to be ableto to see all the stories and filter them out based on this little icon right here. And I'd like an easier way for my teams to be able to do that. So what I'm gonna do is I'm gonna set up a quick filter. And if we have back into the board settings over too quick filters, let's call this bugs only. And our query is gonna be pretty simple. I'm just want the issue type to be bugs. Add that in and is not valid. Oh, because it's bug, not bugs. There we go. All right, so now that we have our bug issue type as a quick filter, if I hop back over to my my board and refresh watch up here, we can see that a new quick filter has been added. And now I can filter by bugs on Lee. And with that in conjunction with the swim lanes, it makes it really easy to see that. Okay, these are the bugs for the payment system. Thes air the bugs for the interface. These air, the bugs for the app log in and It just kind of helps compartmentalize and really helps the teams organize all of that. All right, so in this video we learned how to ah, we learned about the board's filter and how to make sure what issues are showing up properly on the board. We learned how to take the epics and make them swim lanes. We also learned how toe add in a quick filter to very quickly and easily show on Lee the bugs on the board. Now let's move on to our next video because we need to create some new columns for this board to be able to send the issues over two. Q way to get tested, so we'll take a look at how to do that in the next video. 7. Adding new columns: In this video, we're going to create a new column that will use as the trigger to send issues over to the Q 18. So to do that, we need to hop into the board settings, and we can get there up in the top right hand corner. The three little dots Goto board settings once were in the board settings atop over to T columns settings. Now, while we're in here, all we need to do is to really create a column. And the reason for that is because currently, this project is using what Jared calls a simplified workflow, and we can see that right here. Now if your project does not use a simplified workflow, then we'll walk through that in the next couple videos and kind of understand how we can do that if you're not using a simplified workflow. But in a simplified workflow, it's well, it's It's a lot more simple. That's kind of a point behind it. Basically, what Ghira does is when you create a column, it's also going to create a status and automatically map all of that for you. So it kind of does a lot of the work for you. So while we need to do here since we're using a simplified workflow, is to add in a column called Send two Q A It ad, and there we go. So we've added in the column. A new status has been added as well. This is the status here that's been mapped to that column and jeer A has done a lot of that work for us, and that's really all that there is to it. And that's why they call it a simplified workflow, because Jura is doing a lot of the work for us behind the scenes. Now, if you're happy with this bio means, feel free to skip the next video. But if you're using an older version of Jiro that does not have simplified work flows, Or maybe you're just like me and you want to know exactly how things work under the hood for those times when things do go wrong. Well, let's turn off the simplified workflow for this project and look at how we can create a new status and a sign it, too, are sent to Q A column without using the simplified workflow. And we'll do that in our next video 8. Working without a simplified workflow: in the last video we created Ascend to Q A column using a simplified workflow in this video , we'll look at how to get the same result if you're not using a simplified workflow. And as I mentioned in the last video, if you're fine with a simplified workflow and that's what you're using, you can skip this video. But if you're not, let's get started by first clearing out what? We just had it in the last video using that simplified workflow. So I'm gonna come in and delete this column here and now we want to actually get rid of that status because we're going to recreate it through the process in this video, so the status is still there. But let's actually delete that. So I'm gonna come into my settings over here issues, and then if we scroll down over here on the left hand side, we will see statuses and the status that we want to get rid of is this center que way that we had created. So this is actually still applied in a workflow, so we can't actually delete that. So what we need to do is to deactivate that from the workflow. However, we can't actually do that because this workflow is still active. So first we need to create a new workflow and then apply that to our project. And that will make the current simplified workflow inactive so that we can get rid of it. Okay, so that would make more sense as we walk through this. So I'm gonna come in tow work flows here and let's create a new workflow. So add workflow. This will be called This will be our death team. Workflow. Add this in now. Right now, this workflow is currently in active and what we want to do is to make it active on the Dev team project. But we don't have any of those other statuses in that the Dev team workflow is currently using. So let's start to add those in. And I want to make sure it's open this up in a new tab because I want to make sure that I get the right workflow. Someone of the white status is rather some one of you the existing ones. So these are the existing status is that we're using and basically I'm gonna add all of these back in except for send two Q A. Okay, so let's come in and add in our backlog so you can see this status already exists. We're not creating a new status. We're just adding in one that exists. I'm gonna allow all statuses to transition to this one. And that's going to allow all of these two to transition all of the different statuses to transition across each other. And the backlog is actually the one that is when a new issue is created, it's added into backlogs. So let's come in here and add that over here. Yep. And this? We can actually remove that status because we don't need that anymore, because that's not one in the current workflow we have selected for development. So that's another one. I could just add those in. We have in progress, and again, I know I'm moving pretty quickly on here. This is something that I mentioned the very beginning of this course. Ah, this is a high level course. So if you're not familiar with work flows and how work flows work in general, I would recommend checking out my understanding Jerrick horse. And that's much more kind of introductory level on a lot of the concepts injera, including work float. So we need done now. That's the last one that we should need to add in. There we go. Done. Add that in and all right, so we have all of our statuses, except for Sen Dick you A So I'm gonna come in and we need to apply this workflow to the project. So to do that, we need to actually take the scheme and apply the workflow to that scheme because let's take a look at this. I'll show you what I mean by that. Um, so let's come into our workflow schemes and we can see currently the Dev Project. This project is using this scheme and it's using the workflow. It's saying, OK, any of these types So we could have different issue types using different work flows if we wanted to, and so we could get this to be a lot more complex where we say, you know, bugs worked go through a completely different workflow, and so ah, we only want the bug issue type to be able to be assigned to send a que way. For whatever reason, we might want to change that. Uhm, I'm going to keep this a little bit more open and less restrictive and gum start with that . They're so I'm just gonna come in and edit this workflow scheme. And rather than use this workflow, let's add an existing workflow. That is the new workflow that we just created, all on assigned issues and that is going to overwrite the the workflow that we currently had assigned there. Okay, so when I publish this, that's going to update that. And it's basically saying, OK, all of these statuses air good. Except in this new workflow, there's no center Q A status. So if there's any issues that are currently in that status, I need to know what you want to map. That, too. We can see that there's currently no issues in this status, of course, because we just created it. And so it's fine. I'm just gonna leave this at the default associate that cause really nothing's going to, um, nothing's really going to move, since there were no issues there. So let Jared do its thing. Once that's done, that workflow is published. And so now that that new workflow is a signed effectively, what we've done is we've replaced the simplified workflow, so we're not using the simplified workflow anymore. And we could even change this title here just to make it a little more straightforward that we're not using the simplified workflow anymore. All right, so now that we have that, let's add in the status, Okay, so the first thing I want to do is let's just walk through. This is if we need it to actually get rid of that status and replace it with something else . Um, weaken. Do that so we can see. It's still not letting us delete that. What is that? Oh, it's because it's still it's still in that workflow. So let's come back over here to the work flows. And now that workflow is no longer active. But now that it's inactive, I can edit this and I can come in and remove this status. There we go. So with that removed now, if I come over to the status is you can see now it's not associated anywhere. We can delete this status and there we go. Okay, so we've walked through that, and we've effectively gotten rid of everything that we did in the previous video and with the simplified workflow. And we've also replaced the simplified workflow with a new workflow. That's not the automated, simplified one that gear is using. So now what we need to do is to basically recreate that status that we just got rid of. I just want to show how we can walk through that process. So let's hop back into our work flows here and let's edit the workflow. And with this here, we can add in a status. And now, if I do a send a Q A status, you can see it doesn't exist. So this is gonna be a new one. Add that in and want to make sure this is in a in progress category because that's in progress that we go. It creates and there we go. I just like to organize these a little bit better. Doesn't really matter how you have, um, organized. That's just a visual thing. But with all of these added, none of this is going to apply until we actually publish that. So this is not actually live until we publish, so we publish. No, I don't want to create a backup and published that and now it is currently active. So now that this is activites active in the project, and if you remember, the board that we created in a previous video is also assigned to that project. And so that's how Jeron knows that these are these statuses that are going to be used on that board. All we need to do now is to make sure to map those statuses to the different columns on the board. Okay, so let's hop back into our projects and come over to projects here. Find our Dev Team project, and that'll get us back to the board. Once we're on the board, let's come over to the board settings and we can see okay, these air statuses that are not mapped yet. So let's add in a column. And now, when I add this column, you'll see this is different than what we did in the previous video. It's not automatically adding the status. Okay, so all of that was to kind of show some of the automation that's going on behind the scenes . When you're using a simplified workflow, you can see we're no longer using a simplified workflow. Now we could get back to a simplified one if we wanted to, by clicking on this here and walking through that process. But I wanted to show both sides, depending on how your projects are set up, and now all we need to do is to take this, drag it over there, and we've mapped that status. So basically, what this means is that when someone drags an issue from to do or in progress over to the center Q. A column. It will a sign the status of center que way to that issue. All right, so with our Dev teams board created, let's move on to our next video, where we will create a different board for our Q A team to use. 9. Building the QA team board: in this video will build our key ways team board and because we've built the board before for the DEV team and we've learned how the process for simplified work flows and non simplified work flows, work will move a little bit faster because we've done all of this before, All right, So let's hop over to our menu here, come into the boards and let's just create a new board from this here now, from some of the meetings that we had with our team leader before we learned that The Dev team needs toe have sprints. But the Q A team does not, and so we're gonna do a can ban board for the Q 18. So if we create that, create it from an existing project that we go, this is our key way Team board project is Dev. That's fine. Location is the Dev team. All of that can live in the same place. That's fine. Go ahead and create our board. All right, so now that we have our board, we have some changes to do for this. Set up for one on the Q. A team we only want to be able to see the bugs. We don't need to see stories like these stories here. We don't need to see any of the epics. You can see the epics here. We don't need to see any of those. All we need to see are the bugs. OK, so let's come over to our board settings and come into general. And as we talked about in a previous video, the what determines what issues are seen on the board is this filter right here. So let's edit this filter query. And when we do that, we can see basically what gear did when we created. We told that we wanted to see the issues in The Dev team project. It just selected this Dev team and it shows everything inside of it. Okay, so we want to change that. We only want this to be the bugs in the project. Okay, so say that Now let's hop back to our board for hot back to projects and the Dev team and our 2 18 board right here. Now all we can see our the bucks. OK, so if we hop into our our Dev team, the actual sprint we can kind of walk through what this process will look like. Okay, So I would highly recommend as you're building these out, walk through the process as your teams are going to do on a daily basis. And that way you can start to find out where where the bugs are in your own process, and start to fix those before you ever present them to the team. All right, so here on The Dev team board, we can only see the bugs. It's because we have the quick filter turned on, but we can see that all of the other issues are there as well. But if I take this bug, what I would like to do is when this bug is in progress that the team is working on it. The developer is working on squashing that bug, and then when they're ready to, they think it's done. They want to send it over to the way they drag it into the center. Q. A column. Now, when they do that, it should show up on the the ah, the key way teams board and we can see over here it does, but it shows up as in progress. Not only that, but We can also see the other bugs as well. So what we want to do is tow. Have these bugs hidden and not shown on this board and this bug show up into do when it's dragged to the center. Q. A column on the Dev team board. So to do that, we need to adjust some settings in this board for the Q 80. And we do that in the columns here because what we're doing is we're changing what statuses are mapped to different columns. So as we talked about in a previous video, basically, that's the way the columns work on on boards inside of Jura is these statuses? Here are anything that is in the to do column is going to be either selected for development, or we can see the two issues that are in the backlog status are showing up there because they're mapped right here. We could unmapped them by dragging them over here. We can take this. Send a Q A. Move it into the to do column, and so what's goingto happen is now if we come back to the board, we will Onley see the issues on the bugs rather on this board when they are in the send two Q. A status right here. OK, so let's walk through that. If I take this okay, it's in progress, and then I or we say it's in the backlog. So with all of these, we can see it's going to disappear. There's nothing there. We take this over to send a Q A and you can see it's going to show up in the to do column. Now we're going to run into a problem here, and it has to do with this in progress status. Okay, so this in progress if the deaf teacher I'm sorry, the Q A team is working on this and, ah, they're working on fixing it in the dragon and in progress. So we know that what they're working on over here on the Dev team, it's also going toe update. And the reason for that is because, as we talked about earlier, really, all that we're doing when we're dragging issues from one column to another is we're changing this status right here. And so it is in the in progress status and on our board we have in the board settings. If we look at these, the in progress status is mapped to this column over here. So what we need to do to fix this is to actually create a new status in order to be unique to the Q 18 and put it in this in progress status. All right, so I know we covered a ton in this video into recap. Basically, what we did is we created our Q 18 board. We adjusted the column so that the statuses will be mapped so that the center Q A status shows up in the to do column. And then once the Dev team drags the issue over to the Send a Q A column, it will show up on the Q 18 board in the to do column. But we still need to fix this in progress status so that it will Onley show issues that are in progress for the Q 18 not the Dev team. So let's take a look at how we can do that in the next video 10. Creating a new status: In our last video, we created a board for our Q 80. But we came across an issue where the bugs are showing up on both the Dev team board and the Q 18 board when they are in the in progress status. So in this video, we're going to create a new status and separate out the in progress for the Dev team and the in progress for the Q A team. All right, so let's get started here by coming over to the project settings, and what we're going to need to do is to add a new status. Now, I do want to point out if you are using the simplified workflow, you could do that by adding a status over here. But we're not doing that as we actually walk through the process of decoupling that in a previous video. So let's hop over to the project settings come into our workflow and in the workflow. If we edit this, we can add in our new status. Okay, so that's at a status. This will be Q A in progress. So be a brand new status. Allow all statuses to transition to this one. Add this in. It's an M progress category status it creates, and there we go. All right, so we have this new status. Now we need to publish this workflow so that that status will be active in our project. Once we publish this, then we need to hop back and tell Jura how that status is going to be used on the board for both our Q A team and the deaf team. Because the Dev team is in the same project, so it now has access to that new status as well. But we don't want to show up on the Dev team board. We only wanted to show up on the Q 18 board, So let's hop back to the project here. And let's start with a Q 18 board because that's where we are. So let's come into our board settings and in progress. So now this in progress is going to be on Lee for the deaf team and a Q A in progress is going to be what is used here. Okay, so if I come back to the board now and I take this this issue here, this bug that is being worked on and it's drag its in progress. It should not show up on the Dev team board. You can see it just disappears from the Dev team board. So the Death Team board is completely oblivious to that particular status. And we can verify that by coming into the board settings and seeing that it is not mapped anywhere, which is exactly what we want. Okay, so that is the basic process that we're going to be using in order to have have issues or the bugs show up or disappear on different boards between the Dev team and a Q 18. And if we hop back to the Q A team board. What we need to do next is to have the Q 18 be able to drag us over to done. But I would like for them to be able to drag it into either the ability to pull it back to the Dev team or to just say that it's approved and close it and have it disappear from this board and the Dev team board. So if we just drag it over here right now, it shows as done and it will also show up on the Dev team board as well, because again, we're using that same status. So let's move on to our next video because we need to create a few more statuses in order to be able to control what this done column is going to do for the Q a team. 11. Adding statuses to our QA board: in this video, we're gonna add in some new statuses for our Q A team's board so they can determine if a bug needs to be sent back to the development team or if it's approved. So to do that, we're gonna have to hop back into our workflow, and we've done this a few times before, So we'll move a little bit faster here and hop into the work flows. We're just gonna add in two more Status is for this. So let's edit the workflow and here we go. All right, so add a status. This will be key way. I'm just gonna keep it consistent, so we know all the Q A statuses or the key way. Specific statuses are. Start with Q A. So cue. A needs fixes that we go allow all statuses to transition to that one creates. We can just again the order over here. I mentioned this in a previous video, but the order here doesn't really matter. It's just a visual visual cue, and then the next status we need to do is Q A approved. So this is gone through Q way and it's been approved, okay? And this is a done status. There we go. All right, so with these here, what we need to do now is to actually updates are bored to tell it what columns these statuses live in. Although before we do that, we need to publish this draft so those statuses will actually go live with the workflow. All right, So with that live, let's hop back to the project here and on our board. So this is our DEV Team Sprint board the top over to the Q 18 board and come over to settings up in the top, right, the board settings. And we need to adjust some of this. So the done column. We don't want the actual done status that's going to be for the Dev team. We want approved and we want needs fixes. So when both of these are on the same column, watch what happens. I come back to the board and I take this and I drag it over there. We have the ability to drag it toe either needs fixes. You can see it turns green or approved. Okay, Now, if we wanted to, we could have this in a different column, and that's really a matter of preference. Um, that's going to be something where you sit down with your team leader and their and their team and figure out what works. Usually I prefer to start with less columns, if possible. And then if they want it to change, then I will change that for them later on. In this particular case, they were perfectly happy with less columns and having them both on the same so they could drag it to which everyone they want and then ah, being able to control that here. So with this on here, if I drag this into needs fixes, nothing really happens, right? We can see that the status changed, so that's right. But nothing really happened. It doesn't disappear from this board, and it certainly doesn't show up over here on the Dev team board. If anything else, it actually just disappears. Right? So what we want to do is to adjust this board to show that particular status and again, this could be something where we could have a different column if we wanted to tow, have it show up. But I'm going to keep everything as simple as possible in keep it on a single Arnas on a single column here. So that way they don't have Aton of different columns to pull things through. And we can always adjust that later on, depending on your team's needs. So with this, anything that is Kuei needs fixed. We need to take this and put it in the to do board now that to do column. So what that's going to do is now, If I come back here, you can see this issue is back in to do. Okay, so here's kind of our our workflow as it goes, so this is in progress. It's sent to Q A. And once it sends to Q way, we want it to disappear on this board. But we also don't want this issue to actually Ah, we want to be able to see that status on this column. So a little trick that we can do to get it to disappear here is in the board settings not changed this. We don't wanna have this unmapped because we want to be able to map it there. But if we come into the filter recon, tell Jura to not show any issues that are in the Centre Q A status. And so that way we can actually still add it to that status. But as soon as we do here is going to say, Oh, that is outside the bounds of this filter and hide it from that board So we can take this weekend. Select all of these others if we want to and basically hide everything but that one status ? No. If we don't want to do that, we could come in and we can make this a little more advanced. Weaken, say the status. Let's erase all of this and say these status is not equal to that status here, which is the Send two Q way. So it's not in there. There we go. Send two q A. And now if we search that, we get pretty much the same result as we had before. It's a matter of if you want to check all of the statuses except for that one, or come in to advance and do that. So once we save this, when we head back to our board, I can close out of this. Let's open up the dead sprint board and we can kind of get an idea of where this is going now. So let's track this. Actually, let's take this and let's drag it back to needs fixes, and that's going to get it to show up on our DEV team board. So here we go. So it's showing up here. The Dev team tracks it in progress. They send it to Q and watch what's gonna happen. This is going to disappear. So as soon as we drag it on there, it will disappear because it's in the San Dick. You a status there we go might need to actually refresh the board in order to get it to disappear. It shouldn't it should refresh within a few seconds. I kind of it determines how long Ajira takes for it to actually realize that it's in that status, and it should not display that with the filter. But with that disappearing from this board, it will show up over here on the Q 18 board. They can take it through in progress and they can decide does it need fixes? If so, put it in here and that's going to make it show up over here, okay? And we can also have it disappear from this status in that exact same way. So if we come into this board setting and we adjust the query weakens, say, over here, let's say the issue type is bug and the status is not equal to Huei needs fix, which I believe is the name of the status that we did. So search there. Yep. Okay, so save this and now our workflow should be getting a lot closer to where we want it to be . The Dev team takes it through in progress. Senator Q A. It will disappear from this board on the Dev team board once Jura realizes that it's actually in that status. There we go and then over on the Q 18 board. If we look at that, it will show up in there to do is something they need to test. They walk through in progress, and then, if they need to, they can send it back to the Dev team and it will disappear on the Q 18 board again. How long it takes actually disappear will depend on how long it takes Jura to realize that it's in that status and refresh that filter there might take a few seconds. You can always just refresh the board to refresh the page is you need to. And then over here on the Dev team board, it will show up again as something that needs to get done. Great. Now there's one more thing we need to do on the Q A team board. If you recall there's two status is there. There's needs fixes and the Q A approved, and what we need to do is if it's approved. We wanted to actually disappear from the Q A team board, and that process is pretty much what we've walked through so far. So when you're ready, I'll see you in the next video where we'll tackle that. 12. Adjusting the 'Done' statuses: in this video, we're going to adjust the done statuses on our to board. All right, so here's basically what we need to do, and if you walk through this process, it'll make more sense. So our Dev team has a bug that they need to work on its in progress, and it's not going to show up on the Q 18 board. We can open this in a new window if you want to see that, so we can see there's nothing here in progress. So nothing showing up, it doesn't show up on the Q 18 board until we drag it into the Seine Dick you a column. It will disappear from here, and it will show up over here on the Q 18 board so we can see it disappeared here, and it shows up over here. Now the Q A team. When they're working on it, it's in progress. And so it's in progress here. It does not show up over here, as in progress on the Dev team board, and then when the Q A team is done with it, they can either say it needs fixes, so they drag it into that top one you can see the green. When they do that, it's going to disappear on this board and it's going to show up. Back over here is something that needs to be done, and that loop is going to just cycle right until it's actually fixed. And, of course, the idea is that the Q A team is going to add in the comments kind of show screenshots, whatever it is to show, you know what still needs to be worked on and then the Dev team as they drag this through. The other option is after they send it to Q way. The Q A team is working on this, then they decide that it's actually approved. The Q 18 approves it. They drag it into this bottom one. So when they do that, we have a choice Right now. This is what we need to fix. What happens when this issue is dragged into the Q A approved status and there's basically two different choices to key choices we can have, and this would be something I would recommend talking to your team were about to decide which one they prefer. One is if we wanted. When this disappears or when this is approved over here, it can disappear from here. But then, just like the fixes, we could have it show up over here in the done column. And that might be something that they want to review those bugs at Sprint time in order to be able to see how that is. And if that's the case, we do exactly what we did with needs fixes. We just map that status to this board here and then hide it from the Q A team filter for the board. We walked through that process with the needs, fixes status. We would just do that for the key way, approved status as well. But the other option is that maybe we just wanted to disappear from all the boards once it's done. And that's what we're going to do in this example, because in the real world scenario, we're basing this on. That is exactly what the team leader wanted. They didn't want to be able to see it once it was done. Once the Q A team approved it. It's off the plate. That way. The Dev team doesn't have to worry about it anymore, So if that's the case. Once this is approved, all we need to do is to hide this status from this column. We don't need to do anything else on that board now. One other thing I do want to point out is Jura has the built in ability to do releases, so you could do that as well. That's another option again. That's something you'd want to talk to your team leader about, and basically a release that's outside the scope of this course. But basically you're going to create a version. So whatever the version ing is for your software or Web site, or however you want to manage that, and then it's going to tie anything in this done column as a done status to that version. And then that way you can go back and look and see. Ah, what do we release in version two? Oh, these bugs were fixed, all this kind of stuff, and that could be helpful for change logs and tracking all that kind of stuff. But in this case and again, this is based on a real world scenario. They just wanted it to disappear. They didn't want we didn't want to track it anymore. It was It was just done. It doesn't get deleted, but they wanted to disappear from these boards. So if that's the case, all we need to do is to come into our board settings and adjust this filter query in order to say, Not only do we not want the needs fixes status to not show up, but we also don't want the Q A approved status to show up, either. Okay, so there's a lot of different ways we can do this. Probably one of the simplest is to just come in and say, and the status is also not que a approved. And there we go. So that is our new filter. So if we save this and we hot back to the Q A team board, that issue will not show up in this. In this column now, it doesn't actually delete it. We can come over here and we can see Ah, this issue is actually still an issue. It's been approved. It is not deleted by any means. And so if we need it to reopen this, we could bring it back into you know, the needs fixes or the backlog or whatever status we want and that would bring it back into that same loop. So we updated that to be in the needs fixes status. And if we hop over through the Debs team Sprint, that would make it pop up back in this board, in which case it can walk through. That same process is in progress. Send a que way it will disappear from this board. Once this board refreshes. If I just refresh, you can see it's going to disappear, and then it will show up on the Q 18 board over here. They can walk through their process in progress, and once it's approved, we refresh and it disappears completely. It's also no longer on The Dev team board either, which is exactly what we want. Okay, so this has all been, uh, pretty much through statuses. We haven't done anything with who these issues are assigned to, and it would be super cool if once this issue is sent to Q. A, you can see right now it is assigned to Christian Babbage, right? So he is on our dev team, and as soon as this is sent over two Q a really cool. If we could automatically assign that issue to the different team and then again on the other side. Once it's sent back to the DEV team, have it automatically signed back assigned back to the Dev team. But before we do that, let's take a quick step back from Jura to understand how our teams are organized in this example. So that way will know who needs to get the bugs assigned to them as their passed back and forth between the boards. So I'll see you in the next video, where we'll get an understanding of how our teams are set up. 13. Understanding our team setup: in this video, we're gonna take a step back from Jiro for just a couple minutes to get an understanding of our teams and really, who we want to auto a sign issues, too. Now the reason why I say who we want to auto assign them to. Because if you recall from a previous video and we're talking about sitting down with a team leader, the development team that I built this out for initially practised pair programming. But there is a limitation inside of juror where each issue can Onley have one assigning. So the work around that we figured out in this real world scenario was to basically a sign , a point of contact that the issues would be assigned to. And then that person would change the assign me or do whatever they need to do to that ticket. But that way they knew that they were the ones that were the point of contact kind of one accountable for making sure that those were updated inside of Ghira. So on the Dev team, we have ah, three people. There's Christian, Gretchen and Helen and sitting down with the team leader. This was a question that I asked them, and they kind of decided that Christian would be the point of contact for the Dev team. So when we auto assign issues inside of Jiro, we're going to automatically assign them to Christian And then on the Q 80. Now, in this particular example, it's the same team leader because the same team leader was, uh, over both ACU 18 and The Dev team. But we sat down and figured out who was going to be the point of contact over there and again. There were three people Maximilian, Isaiah and Josie, and in this case, it was Josi that was determined. She wanted to take on that responsibility and be that point of contact. So on the Dev team, any issues they're going to be assigned to Christian automatically assigned, I should say, And then he can move them around, however he needs to. And then on the Q A team, those issues are going to automatically be assigned to Josea. All right, so now that we have a good idea of our teams and kind of who's going to get those issues auto assigned to them, let's move on to our next video, where we're gonna hop back into JI era and set up the workflow to automatically assign issues from the Dev team over to the Q A team once they are dragged into that, send to Q A column. 14. Auto-assigning issues to our QA team: in this video, we're going to automatically assign the issues that get dragged to the Send Q. A column on our DEV board over to Joe See the point of contact in the queue. 18. All right, so to do this, we're going to need to adjust the workflow for our project. We've done this in previous videos, so should be a fairly straightforward process by now. Top into the project settings. Come over to work flows and edit this workflow. There we go now. In previous videos, we learned that when you take an issue and you drag it from one column to another on the board, what it's really doing is it's changing the status from one status to another, and that what status it changes to depends on what? Ah, what's what the's statuses are that we have mapped to those columns in the board settings. So these are all the different statuses. But when it changes from one status to another injera, that is called a transition, and these right here are all of the transitions. Now, these transitions just happened to be the same and by default, unless you have a specific reason not to I would recommend keeping allowing all statuses to transition between each other. So basically what this means is, if you have an issue that is in progress, the in progress status, it can change to send a Q A. It could also change to done. It could change to selected for development. It could change the backlog. It can change toe any of those. You can lock that down a little bit more if you want to. To say if something is in progress, it can Onley move to done. It cannot be moved to send acuity. Those are things that you can control. But in my experience, that ends up being a lot more difficult, cause then you have people asking you why they have an issue in progress, that they can't move to Q A or something like that. And so take it from my experience, unless you have a specific reason not to. I would highly recommend just leaving the allow all statuses to transition. So what we need to do in order to change this Ah, the assign e for an issue once it's transition is to come into the actual transition. If we click on that then we can adjust The post functions. So basically what it's going to do is it's going to say OK, the issue is is changed its transition from one status to another, and as soon as it has, then it automatically does whatever we want in this case. Assign it to another user and we're doing it Onley to this one status. Okay, so let's change the post function. If we open that up, we can see all of the post functions that are automatically assigned these air default out of the box from gear. I haven't made any sort of changes to this, but let's come in and add a post function. And here there's a lot of different changes or a lot of different options that we have. And one of them, I do want to point out, is assigning it to the lead developer. And that is pretty much what we're doing. Really, what this does is it works with another feature inside of Jiro called Components, and we haven't really touched components in this particular course because the real world scenario that we're basing this on the team's didn't use components, and so that was not relevant. But if you do want a course that coverage components, that kind of how that works, bio means let me know and we can cover that. It's just outside the scope of this particular course. So what we want to do is to change the assigning. So I'm going to update the issue it ad, and then we have a choice between the different fields that we want to change. In this case, ours is already selected the Assign e. So let's select that. And we know we wanted to go to Joe See, So let's type in Josi and it will find her. There we go, it ad and there we go. So now, once an issue is sent to Q A, it will not only change that status but the post function. It will also change the assigning of the issue to be Josi. So she is the point of contact and then, from there in the queue 18 she can assign it to whomever actually needs to work on it or work on Earth to herself or do whatever she needs to do now. The final step of this before we actually test it to make sure that this works is to publish the draft any time we're working on a workflow by default gear is gonna make a copy of that and you're gonna be working on the draft. The reason why it does that is because if you're making changes to a workflow and people are actually using that workflow other moving issues in and out of the project or doing whatever they're doing on a day to day basis as you're working on it, that can really mess up and and break things. So you actually want to publish it to say Okay, I'm good with this. These changes and we're ready to go ready to make this life. So we publish that. No, I don't need to save a backup copy hit publish. And there we go. So that is now active. So what should happen now is when we taken issue and send it into Q A. Should automatically assigned to Josi. So let's test that I'm gonna close out of this. Let's head back to our project and in our Dev team, I want to open up both boards just so we can see what's going on for both different teams here. So I'm gonna open up the war on the Sprint board for The Dev team and the Q 18 board so we can see what this will look like. Okay, so nothing currently on the Q 18 board as the Dev team is working on it, the taking in progress and then they send it to Q A. Watch what happens? This is currently assigned to Christian right here. Watch what happens. As soon as I do this, it's going toe update and assign it to Josea. And then, of course, it will automatically remove this from the Dev team board. Ah, once Jura updates and realizes that it's should not be there. So we may need to refresh the board and we refresh the board. And there we go. It's it's disappeared. It's no longer there on the Q 18 board. If we come over here, we can see. There we go. It is currently assigned to Josea. Now we need to actually build the other side of that because once Josi works on this or whoever she's assigned toe work on this, if we were to send it back and it needs fixes and we send it back to the Dev team and I send it back there. Then what's goingto happen is if I refresh. This disappears from the Q 18 board, but over here on this board, it shows up. But it's still assigned to Josi, so what we need to do is to basically do what we just did, but then assign it to Christian once it's actually sent back to The Dev team board, So we'll take a look at how to do that in the next video. 15. Auto-assigning issues back to our dev team: In our last video, we walked to the process of making sure that when somebody drags the ticket into the center Q A column, then it gets automatically assigned to our point of contact in the Q A team, which is Joe. See in this video we're going to continue on from that. And once the Q A team is done with it, if they need to assign it back to the Dev team, we want it to be assigned to the point of contact in the Dev team, which is Christian. So let's start with this because the process is pretty much the same is what we did in the last video. We just need to do it for the DEV team. So the top into the project settings and come in tow work flows and at it. And we're moving a little bit faster because we're more familiar with this now. And this is the text view. Personally, I like the diagram view. Um, that's just my personal preference. You could do pretty much everything, but if you just switch here, it's just a matter of how it's how the workflow is viewed. So what we need is not send a que way. But when Q A sends it back to the Dev team, it uses this status. Here we look at the board, the Dev Team Sprint board. We can see that this issue here because it was taken back at the end of the last video. It's in the Q A needs fixes status, so hopping into the board settings weaken. See, that's the, uh, the status that is used when the Q A team sends it back. So that's this one right here. Adjust the transition, go into the post functions, and we need to add a new post function on this post function is the same as the last one update. The issue field and the field that we're adjusting is going to be the assigning, and the assigning that we're going to change is to change it to Christian. Here we go. Add that in, and that should all be good to go. And the final step is to publish the draft for our workflow to make that live. There we go, and with that published now we can test this process and make sure that it all works. So let's head back to our Dev team board here, and let's take this. So this one here lets send it to Q A so that it shows up over there and open up the queue 18 board so we can see and kind of walk through this process. Right? So the Q A team they get, Ah, bug that they need to work on and they're working on it. It's in progress. Ah, it is no longer on the Dev team board. It disappears from there. Everything is good to go and then the Q A team is done. But you know what? It needs some more fixes, so we need to send it back to the Dev team. They drag it to the top one. You can see it's green. That's the cue. A needs fixes status. When that happens, it's going to a change. The Assign me back to Christian, who is the points of contact on the Dev team and then on the Dev team board. It's going to show up in but to do column automatically assigned to Christian. And then this process repeats. The Dev team works on it. He might assign it to somebody else. It doesn't really matter if he does or not. And then we drag it into Q Way. It will automatically assigned to Josi and then show up on the Q 18 board to cycle that all the way through until that is actually approved. Once it is approved, it will stay assigned to Josi because that's fine. We could change that if we wanted to, but it's already done, and then at that point it just disappears. It's no longer on anybody's board. Very, very good. So we have everything pretty much working and really, you could end this here. You could propose this to your team leader and see if there's any changes that they want you to make. Now, in the next video, we're gonna do an optional step, and that's something that I'd like to just kind of go above and beyond sometimes. And in this case, I thought it would be nice for the for the Dev team to be able to see a difference between the issues that come back from key way and the ones that they're already working on. And so we notice it pops back up in the to do column. It looks exactly the same as all of the other ones. And, yeah, they could click on it and see that the status is different. You know, it's not the q A. Ah needs fixes status. But what if we could visually show them that without having to click on it? Just save them a little bit of time. Well, let's move on to the next video and look at how we can add that little bit of icing to this project. 16. Optional: Adding color cards: in this video, we're going to do something completely optional now, as I was building out this process of this, this workflow for the Dev team and the Q A team. I came up with this idea that, you know, even though it works and it goes all the way through, you know, goes to the Dev team and then it can come back and it's on different boards and all of that works when it comes back to the Dev team board would be really cool if they could see that this was a bug that they already worked on. Now they might remember that. But you know, if you're like me, then you may not remember that as well. So it's just a nice little a nice little way to adjust that. And so, the way that I did this in the real world scenario and the team leader loved this idea and love that I added this little bit onto it was I used a color coordination in order to determine that. So let's walk through this process. So what I'd like to do is once this issue comes back to this to do column, I would like to turn it bread. Okay, so we can come into the board settings. And really, what we need to do is we only want issues that Aaron this needs fix because if you remember this whole workflow that we've set up, issues will only be assigned to this status if they come back from the Q A team. That's kind of how the automation process works. So if we come into color cards, we can base the color cards based on a custom query. So let's say the status equals. Q. A. Needs fixes. There we go. Add that. And so now the color will be red when it comes back from the Q A team. So let's walk through this process and see how this looks. So this is the the bug is that first started? So the Dev team is working on it. It's in progress, and it's transitioned over there. They're working on it. We can hop over to the Q 18 board to see what that looks like differently, and we can see it's not on here because it's not on their board yet. It's not something they need to work on, yet they send it over to Q A. It updates sends it to Josi so that she is the point of contact on the Q A team, and they can update that as soon as we hop over to the Q 18 board weaken. See, it's on there and it disappears from this board as well. And then the Q A team has it, so it goes in progress. The Q A team is working on it and and and testing the bug to make sure that everything is working in this case. Ah, office is working with Facebook. Log in or whatever that bug maybe and again on the Dev team board. It's not showing up there. We don't see that anywhere. And then once the Q A team is done, if they need to send it back to the Dev team and they send it back to the top one and it needs fixes its assigned back to Christian just like we set up in the previous videos and then over here it will show up not only doesn't show up, but its color is red, and that's the way that Jared does. Color cards is as this little line over here, so that's a little bit different. It doesn't change the color of the entire cart, so that's kind of how that works. And it's just a nice little way of visually being able to see the bugs that the Q A team has worked on and it's been sent back. So that way they know that this is one that we've already worked on before, and it needs to be. There's something else that needs to be added to it. ER needs to be fixed on it, and that wraps it up. This workflow is ready to present to our team leader and let them know how little work. And of course, if there's any changes that they'd like, we can always go back and make those. But in this case for the real world scenario that I'm basing this course on, this is exactly the result that we ended up with and the team leader and both teams were ecstatic 17. Course conclusion and where to go from here: thank you so much for watching this course. I hope you've had as much fun over the past hour or so as I have Working Injera is something that can really help your teams be more efficient and effective. And as Ajira administrator, you get to help them get stuff done now. As I mentioned at the beginning of this course, and as you've seen throughout it, this course was not intended to be an introductory level course. That's why we moved very quickly. So as you're working with your team's injera, if you ever need more assistance, by all means, feel free to pass them on to my understanding. Jura for users, managers and add men's courts. That course walks through all of the different features that we used in this course in a more introductory level. And, of course, the workflow we built today is just one of a limitless number of ways that you can build a workflow for. Teams toe work together injera. But hopefully now you're armed with a few new tips, techniques and ideas for how you can take the examples we've learned in this course and start applying some or all of them to your own jeer a set up. So thanks again for watching, and I'll see you again in the next course.