Learn JIRA with real-world examples | Kosh Sarkar | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Learn JIRA with real-world examples

teacher avatar Kosh Sarkar

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

43 Lessons (2m)
    • 1. Course Introduction

    • 2. JIRA - the What, the Why and the How

    • 3. Agile Concepts Refresher + Scrum + Kanban

    • 4. JIRA Terms - What makes up JIRA

    • 5. Intro to the JIRA user interface & navigation

    • 6. Viewing, editing & understanding Issues

    • 7. Working with Agile Boards

    • 8. Creating Issues

    • 9. Searching for Issues

    • 10. Advanced searching using JQL

    • 11. Search Filters

    • 12. Dashboard customization

    • 13. Quick note on navigation & Summary of videos so far

    • 14. Configuring agile boards - Part 1 (Scrum board)

    • 15. Configuring agile boards - Part 2 (Scrum board continued)

    • 16. Configuring agile boards - Part 3 (Kanban board)

    • 17. Creating projects

    • 18. Creating epics and stories

    • 19. Starting sprints and working on sprints

    • 20. Creating software versions in Scrum

    • 21. Creating software releases in Kanban

    • 22. Creating an agile board with multiple projects

    • 23. Closing sprints and viewing sprint reports

    • 24. JIRA Admin navigation

    • 25. Creating a new user

    • 26. Creating groups and access controls

    • 27. Understanding the different permission levels

    • 28. Global permissions explained

    • 29. Understanding Project Roles - Theory

    • 30. Understanding Project Roles - Example

    • 31. Roles and Permissions Example - Part 1

    • 32. Roles and Permissions Example - Part 2

    • 33. Roles and Permissions Example - Part 3

    • 34. Understanding Jira Schemes & Introduction to the Schemes Example

    • 35. Configuring Issue Types

    • 36. Configuring Screens

    • 37. Configuring custom fields

    • 38. Creating a new workflow

    • 39. Editing an existing Workflow

    • 40. Updating the agile board with new workflow changes

    • 41. Understanding Workflow transitions

    • 42. Working with Project Components

    • 43. Other Jira Administration and summary

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

This course walks through all the core features and concepts of JIRA Software on Cloud with real-world examples and has been catered for all users, managers and admins.

JIRA is a very comprehensive tool and one of the most popular agile project management tools out there. When used and configured correctly, it will help you work smarter, faster and more efficiently.



  1. Learn the most important characteristics of Scrum and Kanban agile methodologies
  2. Covers all aspects of JIRA including working within an agile team, leading an agile team, and administering the main things that make up JIRA
  3. Real-world examples including
    1. How to manage your daily task-list via a daily scrum-based process
    2. Configure permissions and projects for internal team members, as well as external members (Eg: consultants, customers etc)
    3. JIRA allows you to create stories and epics for agile projects - learn how to create another issue type used in agile called Spike and create custom screens, fields and workflows for this new issue type.
    4. Modify the default software development workflow to include steps for QA
    5. How to set up an icebox (features that aren't ready to go into the development backlog aka "put on ice") in JIRA
    6. How to build a completely new workflow to manage the approval of new work or feature requests, before being moved into the development backlog
    7. How to manage multiple teams working on the same projects via multiple agile boards catered to each team



  1. Agile Concepts - Goes into detail with Scrum and Kanban methodologies. By the end of the section, you’ll have a full refresher on these methodologies as I made sure I hit the most important notes when it comes to how they work.
  2. Working within an agile team - Get your first look at navigating the Jira user interface and learn how to create issues, work on issues through the agile boards, search for issues, create custom dashboards to see whats happening in Jira and other functions beneficial to any agile team member.
  3. Leading an agile team - Configuring and managing agile boards, creating and maintaining the backlog as well as starting and ending sprints and creating releases. All these steps stay true to the agile steps described in the prior section.
  4. Jira Administration - Goes over all the main administration sections and each part has an example that you can use to follow along with. By the end of this section, you will understand all the customizable aspects of Jira and be able to cater your own instance to fit your own specific needs.
  5. Real-world examples, scenarios and bonus content - This is where I show you how I use Jira to track and forecast my personal day-to-day tasklist, while using a daily scrum-based process, among other examples.

Meet Your Teacher

Teacher Profile Image

Kosh Sarkar


Class Ratings

Expectations Met?
  • 0%
  • Yes
  • 0%
  • Somewhat
  • 0%
  • Not really
  • 0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Course Introduction: Hi there. Welcome to my course on Jura. My name is cautious, Sircar. And not only am I an avid user and administrator of Jura, which is arguably the number one agile project management too out there, I also use it to manage a software development team as well as my own personal day to day tasks to a point where I probably wouldn't be able to live without it. True story. So why am I excited to teach you about year? While Ghira is a very comprehensive tool with a lot of customization capabilities and when I got started with it, it did seem a bit overwhelming and it took me a while to become fully fluent with it. But now that I am, I actually really love it. So I thought to myself, there are probably a lot of other people out there that are going through the exact same thing, whether it is to evaluate Jura and see if it works for them or their teams, or simply just trying to understand the concepts and features of your. So I decided to put this course together toe help with exactly that. Now, why should you take this year course. Well, I have gone out and interviewed developers and scour the Internet to understand the key juror administration concepts that people struggle to grasp initially and have incorporated that feedback into this course and laid out the concept and features toe help. Better understand them and I won't stop there. I'm also going to walk you through riel world scenarios of how these features come together , whether it's an example of how a software development team can use Jura to manage their work through custom work flows, or even how I use Jura to manage my daily task list with a little bit of a twist, because I am able to actually track and forecast exactly what I'm able to achieve in any given day. So in summary, I wanted to make sure I put in a lot of content into this course and make it the full comprehensive guide that anyone would need to either get introduced to Jura or learn and get up to speed with using Jura and ultimately become an expert angina. So let's get started 2. JIRA - the What, the Why and the How: I know a lot of you probably already know about Jezeera, but for formalities sake, let's introduce your and what it is. And also spend a few minutes talking about why you should pick Jura and what your options are for signing up. So Jura can mean many things. But for the purpose of this course, Jura is an agile project management tool that helps you organize tasks and work flows, whether it is just for yourself or an entire team. You could also call it an issue tracker, bug tracker, even customer support tool or general productivity tool, which can really be catered to any team of any size and for any function. It is developed by a company called Atlas Ian that is based in Australia and offer a wide range of collaboration tools that integrate into each other. So if we take a quick look at their website, you can see that they offer these team collaboration tools, whether it's for documentation through confluence or team chatting through hip chat. They also offer some code management tools which all integrate back into gear. Now, a quick note on recent events At last Ian recently acquired trail Oh which is also another property popular productivity's E and team collaboration tool. So you could probably say that Elhassan is doing pretty well for themselves and are one of the leaders in this space. Now you can see here under plan, track and support. They have three different Ghira products or packages, so let's talk about them. Jacor is the based software that is primarily used for business related project and task management. Jura software, on the other hand, is what we will be going through and using in this course, as it includes both Jericho or as well as Jiro Agile, which contains the features that are used by agile software development teams. Now, if your team is also looking for a help desk type solution, Gear also has something for that which they call service desk. So why'd year? There are a lot of productivity's tools out there, but from what I've seen in the market, I feel the Jura is arguably the number one software development tool used by agile teams. Now I know saying something like that is subjective. But while I was doing my research, I ran into this chart on Wikipedia, basically comparing features of various issue tracking systems, and you can see here the Ajira pretty much checks off on all of them. A major competitors to jeer, you might say, would be pivotal tracker, which is also a pretty popular tool. But you can see that they do not support customizable work flows. So there were more products in this list, but unfortunately I wasn't able to fit them in the screen. But if you get a chance, feel free to check out the link on Wikipedia. So overall, Jura has a lot to offer, whether it is for simple task management or flexible, agile based projects, It is everything you need to manage an agile team and can adapt to your team and the way your team works. Also jeer a happens to be open source. So Atlassian has their own marketplace, where you can find several third party add ons to add on to the default functionality that Jiro already provides you. So if we visit this link for a quick second here, which I have open and under Ghira, you can see all these add ons that are offered by third party developers. So they've got things for time. she'd reporting, Um, or they haven't excel. Add on, which is one of the new genera add ons began TEM assuming would help you, Ah, set up Gant charts They've got Zenda support and the list really goes on. So feel free to do searches on your own in case there's a particular functionality you're looking for now. Also, keep in mind that most of these add ons do offer free trials. So if there is something that piques your interest, you can always do a test run and see if it actually achieves those goals. Now, how can you get gear while Jura is available in both cloud subscription and server installation formats? So let's talk about how these two compared with each other. One thing to note and unfortunately there is a downside with Vera is that it is not free. But there are definite, cost effective options that give you everything for a very minimal amount. If you sign him for a cloud, it's very easy. Just create an account and you're good to go. However, you will be paying a monthly fee for it. So, for example, if your team is 1 to 10 users, the fee comes to about $10 a month. The advantage here, though, is that it is very quick to set up, and we'll walk through that in just a moment. The other option is you can do a server set up where you essentially installed era on your own server and access it from there. This latter option becomes cheaper, but there is that tedious installation process that is required. But if you can break through that, looking at that same example of 1 to 10 users, all you would have to pay is just a one time fee of $10 you would get access to all functionality that Jura provides you. Another thing to keep a note is that if you use the server installation, you will have access to more add ons than there are available on cloud. And this is pretty much just for security reasons. That jeer allows more add ons available on server than on cloud. Now, looking at the starter licenses, which is if your team is between 1 to 10 users, they're calling that a started license. This comes with a 12 month support package, which you can renew every year and you can also use these licenses for commercial purposes . And the last interesting thing to note is, alas, Ian donates 100% of started license payments to charity. So not only are you getting an amazing productivity tool, you're also comforted knowing that your payments are going straight to charity. Now let's take a quick moment and walk through how you would get Jura and set up. So if I click on try, you will see that there are two options here on cloud and server, as we talked about. So let me just open these up in two tabs and go through the cloud set up first. So here they have different options. If you're just looking to get gear software, you can do so. But they also have some packages where you can get gear software plus confluence or with service desk as well. So let's just try Jerry software. All you would really have to do is fill out this form click starting now and at Lassie, and automatically sets up a instance for you on the cloud and gives you access, and you can log in and start using Jezeera right away. It is that simple. However, if you want to go through the server installation route that you would need to download and go through that insulation process, do not fear, though I do have some lectures at the end of this course walking you through that insulation process, and I will also show you how you can set up an internal network where you can access your gear insulation from any computer within the same network. So we have talked about what gear is, why you should use it and how to get it. Now, before we get into the nitty gritty, let's quickly go over the structure of this course and what you will learn from it. 3. Agile Concepts Refresher + Scrum + Kanban: agile is a software development methodology that has an iterative approach to development, basically building and releasing software incrementally from the start of the project, rather than trying to deliver everything all at once, right at the end. This iterative approach involves planning a development, adoration, implementing the work planned for that iteration and delivering a version of the product by the end of it. Feedback is then gathered and used to plan the next generation, and this process continues until the product is fully polished. This process allows the team to adapt to changing requirements as the feedback loop starts at a very early stage. So if some requirements change because the rations a relatively short thes changes can be fed into the next iteration, thereby keeping the overall development flexible and adaptive. And at the end of an adoration, there should be a ship, herbal product or group of features. This frequent delivery of the product results in customer satisfaction as they are able to monitor the progress of development and are able to test and provide feedback early on, thereby ensuring that their requirements are met and the team is on track. The goal is to keep requirements and documentation lightweight and flexible. And this can only be achieved by insuring close collaboration between team members, especially between business people and the developers. Now there are many agile methodologies, all of which followed these concepts. To some extent, Jura supports to methodologies, scrum and can been So Scrum is probably the most highly recognized, agile A methodology. It works by breaking projects down into smaller bits of user functionality represented by epics and user stories. An epic can be defined as a larger body of work or work that cannot be completed in a given adoration, and so it usually gets broken into multiple user stories. A user story or just story is basically these smallest unit off work and can represent a feature that is to be developed. If you look at this course as an example, you could say that for the Gear Course project, this jeer a and agile concept section is an epic, and the individual stories within the epic are each of the lectures within the section, including this one. Stories are usually defined using a particular format by specifying the type of user involved, what the user is trying to achieve and the benefit for achieving it. For example, as a manager, I would like to learn about Jura so that I can use it to manage projects using agile work clothes. So once features for a project are gathered and corresponding uses, stories are defined. They are then prioritised and continuously implemented and delivered in short cycles known as sprints. So this is the basic flow off work. With Scrum, you start off with a product backlog that contains all the features you want to build in the form of user stories. The's features of stories get prioritised, so the most important features are at the top of the back look. It's also important that these features at the top of the backlog are in a ready state, with all requirements and details laid out, which essentially means that it is ready for development. A group of features are then selected from the product backlog and made into the sprint back look, basically representing that these features are what the team will implement during the sprint. A sprint is a predetermined length of time, usually between 2 to 4 weeks, where the development team takes the tickets from the sprint backlog and gets them to a done state by the end of the sprint and during the sprint. The team has a daily 15 minutes scrum meeting at the same place and time every day to discuss the progress of the Sprint and make sure things are on truck. And by the end of the sprint, the team should have a ship herbal group of features that can then be reviewed by customers or relevant stakeholders. Now, when it comes to scrub, there are a few rules with specific responsibilities. The product owner basically owns the product and defines the vision of the product. In other words, he or she defines what should be built and why. As a result, the product owner is responsible for defining what goes into the product backlog. He also creates the user stories, prioritizes them and ensures they are groomed with all relevant details. The development team basically builds the product and is responsible for providing ship herbal features at the end of the sprint, and the strong master facilitates the scrum process and basically make sure the team is on track during a sprint and that there are no blockers on anyone that would prevent the sprint goal from being achieved during the scrum process. There are a few events that are critical to being successful. The Sprint planning is where the Sprint backlog is created by selecting the fully groomed and highest priority features from the product backlog that the DEV team can work on during the next sprint. The development team then goes ahead and provides their estimates for time and effort to implement the features. And all of this happens during that spring planning meeting. Now, a quick note on estimation you can either estimate in hours or story points. Story point estimation is basically done where estimates are made relative to the smallest component or item with the known level of difficulty. After a few sprints, the team will know how Maney story points they can complete in a sprint also known as team velocity, so they could use this metric to predict how Maney story points they're going to be able to fit in the next sprint. So once the sprint planning meeting is complete and the sprint starts, a daily 15 minute scrum meeting is held with all the members of the team and mainly facilitated by the scrum master. This meeting is always the minute of 15 minutes, or at least should be limited to 15 minutes. So the team members usually stand up while doing it to ensure that it doesn't go any longer . During this meeting, every team member gets a turn toe talk about what the person did yesterday, what the plans are for today and if there are any blockers now, if there are blockers, this is where the scrum master can step in and work with that team member to get things unblocked and moving again. So the sand up scrum meeting occurs every day of the sprint and at the end of the sprint, there is a Sprint Review and retrospective meeting. The review part of the meeting basically entails reviewing the features or stories that were completed or not completed and working with the product owner on shipping the completed features. If required, the retrospective part of the meeting is to simply reflect on the last print and talk about potential to improve the overall process. Now what happens during a sprint, the team can monitor an update the progress off work through a sprint board or scrum board and this board is one of the major features available on DJIA. In fact, this image is an example of a scrum board from gear. A scrambled is typically structured in the form of columns, and the goal of the sprint is to basically move all the tickets from the left. Most column to the right. You may have seen physical scrum boards being created in offices where they would use a white board, draw the columns on there and use sticky notes to represent the user stories and manually move the sticky notes from one column to another. Fortunately, Jerrod digitizes all of that for us. This example shows the most basic board where, at the start of the Sprint that to do call him basically represents the Sprint backlog, and developers would start working on tickets and move them to the In Progress column. And once implementation is complete, they are moved to the done column. The goal of the Sprint, obviously is toe have all tickets in the done column. This board can also look different for every team, so some teams may want to have more statuses or columns, for example, tickets that are in progress when complete will go to a code review column, and then once code review is complete, it will then go into a testing column before it finally gets to the done column. And some of this customization is possible injera and is actually something that will be doing later on in this course. So every team can change the board and add columns to represent their unique workflow steps , and jeer allows you to do this very well. So this summer, I scrum the product owner creates and manages the product backlog by filling it with PB ice or product backlog items, also known as user stories, which can represent a feature to be developed. A spring planning meeting is then held with the entire team, including developers where the highest priority stories, which are usually at the top of the backlog, the product backlog are put into the sprint back look. During this process, the developers also provide an estimate of effort for each of the stories. The sprint then begins, and every day there is a 15 minute stand, a meeting to discuss the progress of the sprint. The scrum master facilitates this and ensures the team is on track and unblocked. And at the end of the sprint, a review and retrospective meeting is held with all team members, and the product owner works with the team to package the completed features into a potentially ship. A bold product. This is basically the essence of scrum workflow. Now moving on to Kambon can ban is another and more simpler form of agile development. It also entails having a board to visualize the flow off work. However, there are no sprints involved in this case. The main goal is toe have a smooth flow off work from start to completion without any stoppage or bottlenecks. And in order to do this, the team must define what that flow off work entails. As in, how does a particular work item go from start to completion? What are the various steps or stages that it would go through and what is involved with transitioning the work items through each stage and ultimately getting it to a done state? All this would be represented through a can ban board where the goal is to move all work items from left to right. Just like on a scrambled can been, teams can also set a limit on the number of work items in each column off the board. These limits basically represent the capacity of the team. As the work starts flowing through the Cameron board, the team can monitor the state of the board to adapt their processes, identify bottlenecks and make improvements. Here is an example of a can bend board on gear. It looks almost exactly like a scrum board here. There are four columns, so the backlog can represent all the tickets or features that need to be worked on. But he selected for Development column would only include the highest priority tickets, and developers would only start working on tickets that are in this column. You can see here that the in progress column is highlighted in red, and this is actually a feature of Ghira, as I mentioned. Can ban teams consent, a work in progress limit, and in this case, the limit is set to one. As you can see at the top of the column, right beside in progress, it states a maximum limit of one. So since there are two tickets in progress, JIA alert to you about it, and this is where the team can collaborate to look at potential bottlenecks and work to get the board back to a normal state. This is basically the essence of Cambon workflow. So in summary, we've talked about how work flows in both scrum in camp and methodologies. An example of where these grown process would benefit the most is when you have a project with defined features that can be estimated by the development E. This could be a completely new product or project or group of features where the requirements are fully laid up. Can Ben, on the other hand, I feel, would be a good process to follow for things like support tickets as in bugs that are found in the system or a support requests sent to end by end users. The reason is because most of these things most of the time are difficult to estimate or predict, And so the best way to get them done would be to keep the highest priority tickets at the top of the backlog and have your support development team work on them one by one and get them to a done state in the quickest manner possible. While monitoring the work in progress. I also want to end this lecture by pointing out that we have just scratched the surface of thes concepts and discussed them at a very high level. But there is a ton of content on agile scrum and can ban on the Web, and I have provided a few resource is that would be worth checking out if you have time and would like to learn more. So lets no get back into Jura and define some terms. 4. JIRA Terms - What makes up JIRA: Let's take a look at some of the terms that make up here. An issue is the essence of Jura and basically represents a work item, any work item or anything that requires an action from a person. So when you create a ticket, injure, you are essentially creating an issue. In other words, epics, stories, bugs feature quest tasks All of the's are issues of a different issue type. So when you create an issue, you can create an issue off an epic issue type or a story issue type or a task issue type, etcetera. You can create your own issue types, injera as well. But ultimately, every ticket created injera is referred to as an issue. It contains basic feels, such as title description, due dates, priorities, status, etcetera and you can make your own custom fields as well. A project pretty much represents the normal term, or meaning of a project and is basically a collection of issues. It can be a software deaf project. Help the system general task manager so on and so forth. Obviously, if you're looking at using Jura agile or dear software, you're most likely engaging in software development projects pretty much. Everything can be customized within a project, including Who gets access to it. The issue types available in a project. The workflow is used and many more. Which brings me to workflow. Ah, work flu is a set of status. Is that an issue in a project can have along with the transitions between status is that the issue can go through. This image is an example of a workflow and what it looks like injera. So when you create a ticket or issue, it goes into the to do status. From here, you can transition into two different statuses, either in progress or done, and the arrow basically represents what that transition is. So, for example, if I have an issue sitting in the to do state, I could either transition or initiate the transition of start progress, which would take the issue to the in progress status. Or I can initiate a transition called Done, which would take the issue to the done State and transitions and Vera are basically represented by a button on the issue details page. So if I'm looking at an issue that is currently in the in Progress state or what that status. Then I would see two buttons. One would be stopped progress, which, when clicked, would take the issue back to the to do status. And the other button, I would see, would be done, which would take me to the done state. And similarly, if issue is done than I could transition through the reopen transition by clicking on the reopened button back to to do. Or I can click on Reopen and Start Progress, which would take the issue back to in progress. So this is what a workflow is and is fully customizable on Jura to fit your needs. In fact, remember how I said that an issue can be of various issue types such as epic story bug, etcetera and a project, and have different issue types associate with it? So, for example, a software deaf project would definitely want the issue types of story and epics and maybe even tasks. But a General task manager project would only need the issue types of task and sub tasks and not really need stories or epics, since it's just a general task manager and not a development project, so you can associate different issue types of the project and injera, you are able to actually configure a different workflow for each issue. Type within a project to give you, ah, high level taste of how configurable workflow Ozcan be injera now versions basically helped track releases of software. So remember when I mentioned that at the end of a sprint, you should have a ship, herbal product or group of features. So for tracking purposes, Jura allows you to create a version and add whatever issues that are going to be released into that version. You could either create a version at the end of every sprint if you're releasing that often . Or you could create a version over a set of Sprint's where if you've already identified the stages at which you want to release the software, you can create your different versions well in advance and assign the respective issues to each version. In scrum, aversion is usually preplanned and is released when the plan work is complete, whereas in Cambon aversion can be released at any time and will contain all the issues that are complete or in the done state. At that time, do your components are just a feature that Jiro offers to create subsections off a project . They're basically used to group issues within a project. So, for example, perhaps your project is broken into back and development and front end development, so you could create both of these as components and be able to group your issues accordingly. It's almost like a category off work and and an advantage of having components is that you can configure issues created under a component toe have a default assigning so that when created, it's automatically assigned to that person. So, for example, you want all back end Dev issues to be assigned to your lead back and developer, who can then delegate it out to other developers. You can do this through component configuration, and lastly, General also uses the other common, agile terms that we've already discussed, such as scrum can ban backlogs, sprints, etcetera. All right, now that we've identified the main gear terms, we are now ready to take our first dive into Ajira, starting off as a user working within an agile team 5. Intro to the JIRA user interface & navigation: All right, let's take a look at the Jiro User interface and high level navigation flow. I'm going to show you some of the main screens injera, but I'm not going to go into any details on any of them just cause we'll be covering that in future lectures. For now, I just wanted to give you an initial look at the interface and get you used to the overall look and feel. So here I have created a personal instance of Jiro on the cloud, which I'm going to be using for this course. So let me go right in logging in. And this is what I see when I log into Jenna. This is my dashboard and is basically Meiji era home page Over here. These boxes over here are basically what they call widgets, and this entire page can be completely customized. You can create new dashboards, and even on this default system dashboard. You can customize this to provide or display additional widgets. Whether it's specific kind of information you're looking for, it could be a completely different issue list that is based off a specific filter, or you can even display charts so on and so forth and we'll walk through that in in another lecture coming up. But looking at the default widgets that gear set up for me. So this assigned to me, which it basically lists all issues that are assigned to me and below that is an activity stream. So this is almost kind of like a newsfeed injera, and it shows you what's been going on. And what are people doing? And what are the most recent changes that have been done in gear? So this is the dashboard, And above that you can see up here is the navigation bar, and this is pretty much visible from anywhere injera that you can access all these pages from here. So looking at the right, starting off on the right side is your profile. So let's take a quick look at that. A lot of this is pretty self explanatory. You can see your own activity stream over here. You've got your details that you can edit. So your full name email password, things like that, and below that is preferences. So if you want to update your time zone something interesting at the end here is your gear home page so you can actually modify or change your Jiro home pages. If you don't want it to be a dashboard, you can have a display one of the juror agile boards. Or you can even set it to be an issue navigator, which is the page where you would look for issues. So if you notice that every time you log into Jura, you're always going into the issue Navigator page to search for issues, then you're probably better off just specifying that as your homepage to avoid those extra clicks. So coming back here on the navigation bar on the right, this cause is access to Jura administration. Now, since I'm logged in as an administrator, I have access to it. But if you are a user without administration privileges than this cog will likely be missing for you. You've got a search bar that you can search across Jura and let's move over to the left. Here. This hamburger icon is basically a shortcut to access other at lasting products that you may have installed or subscribe to. So, for example, if you had subscribed to confluence, which is at last aeons documentation management product, you would have Ah, link right below, Jerry here to confluence. So the advantage of this, I guess, is you can make Ghira your one stop shop for all at last in products that you may be using . And from here, you can access them easily. Instead of going to those separate URLs by typing them into your browser, you would just come here and you would have a shortcut key toe access them. Obviously, clicking on the Jeryl logo here takes you back to the gear home page, which is the dashboard. As of now, you can also access the dashboard by going into here. And if you created more than one dashboard, you would be able to access them from here. And you can manage your dashboards as well. Now, remember how I said that projects and issues are to off the main things that make up Ghira . While given that this is Jiro software, there's also a shortcut to visit your agile boards because that is the essence of agile is toe. Have a board where you can manage your flow off work. So gear put that up here on the navigation menu to have quick and easy access to but let's take a look at projects, so I'm just going to go here and click on view old projects here I have actually created to sample projects. And that's one of the things that Jiro offers you is that if you want to create a project or if you're just getting into gear for the first time, you can create a sample project where gear would actually populate sample data and you can do that for both Can Ben and scrum projects. So I've created one of each over here. The key is basically a unique identify air off a project and its unique across Jura. So two projects cannot have the same key, and one of the uses of this key is, ah, all issues that it created under that project would use this key to create a unique issue identifier. So, for example, the first issue that I create in this sample sample can Bend project would be escapee Dash one, and the second issue would be escapee dash to, So it's basically a unique identify for all issues. Within that project, the project type. There are two basic basic project types, software or business, given that we're using jeer software, and we're creating agile based projects there of type software. But if your business team wanted to also utilize your to manage any of their business functions, they can also create a project of a business project type. Here is the project lead, which is essentially the person that created the project. In this case myself, the project category is just a additional feature that gear provides where you can organize your projects in a better way. So it's something that you can configure in the administration section. You can set up different project categories, and then you can specify that. Yeah, this project falls under this category, so on and so forth. So it just helped you kind of organize your projects If you've got a lot of projects going on within your organization, the URL is also something similar in that it's just additional information that is tied or associate it with your project. So an example here is that if you are building a new website and that is represented as a project injera, you can come in and you can put in that websites URL into this field, and you can do that in the Project administration section. And, ah, so the convenience factor there is if you are visiting this page and if there's a relevant you URL associated with that project, you can put that in here, and it just gives you quick, easy access to that girl. So that is the project page. Now let's take a look at the issue Navigator. So if I click on the drop down here, Jerry gives me a few options. I can look at the current search, which is basically the previous search that I did, Anja, or I can start a brand new search. I can look at some of the recent issues that I had visited, or I can just click on one of the filters that is available to me. So for now, I'm just going to start a new search, and this will take me to the issue Navigator page. Now, remember when we were talking about the dashboard when we were actually on the profile page and we were looking at how you can change your Jiro home page, which was set to the dashboard, you could change it to the issue Navigator. This is what that page would look like on this pain over here, you can scroll through a list of all the issues. So right now there is no filter. So this is showing me all the issues that have been created in this Jura instance right now . And as you select one of these issues, all those details appear. The corresponding details appear in this pain on the right side at the top. Over here, you've got a bunch of filtering options so I can filter by project or the issue type or status on and so forth. I can go into more advanced features and on the right side, if I just pull out this little pain here, these are a bunch of filters that Jura has already provided me by default. I can obviously go in and create my own custom filters. And Aiken, save them through this process. Over here and on the right side, you've got a couple of buttons for things you can share the filter. You can export this filter list in various formats or you can bulk at it. All the issues and those similar buttons exists in ah, in the issue detail pain. So you can share the issue. You can download or export the issue, and you can do various other modifications and things to the issues, which basically will cover in a completely separate lecture on its own, as there's a lot of stuff that you can do on this issue. Details Page. So this is a high level quick introduction to the issue Navigator page. Now the one thing that's left is going to the boards, but this is even more detailed, and we're going to be talking about this in one of the lectures coming up. But just to give you a quick introduction on the view, all boards page. So here there are two boards, and the reason being is that every time you create a project that is either can ban or scrum, Jiro automatically creates an associated board for it. So, as I showed you, I had created to sample projects one for can ban and scrum so automatically those respective boards were created for me. So it just tells you what the type of board it is, who the administrator is and the filter being used, and we'll obviously talk about this and I'll explain all this stuff to you in more detail when we're going to the specific lecture on the agile boards. So this is a quick walk through of the navigation. So you've got your profile and administration and surge on the right and you've got your navigation flow so you can go back to the home page, which is currently configured to be a dashboard. You can view all projects. You can search for issues or get quick access to your boards, and this button over here is basically it lets you create issues. And obviously given that issues are one of the core features, or this is what basically makes Ajira, Jiro wanted to give you an easy way to create issues so they actually put in a shortcut key to create issues. So if you click on that, you'll be able to go ahead and create issues. So that's it from a introduction standpoint. Now, looking at this dashboard, you can see that this widget has ah whole bunch of tickets assigned to me and as a developer or a member of the development team, you're going to have issues assigned to you. So now let's look at an issue and the details of an issue and everything that makes up an issue 6. Viewing, editing & understanding Issues: in this video, We're going to walk through all the details of an issue before I get started. I just want to point out that I actually logged out of my administrator account and I logged in as another user. So I created another user account and set the privileges as just basic non ad men to kind of give you an idea of what things would look like if you are a user. If you are a member of the team as a developer or part of the Q A team so on and so forth, so you can see here that that caused that I was talking about on the top right is no longer there because I am not an ad men, so I don't have access to all the administration capabilities. So I am looking at the issue Navigator once again, and I have selected one of the issues to go through with you and starting off of the top of the issue. The sample storm project here shows that this issue is part of that project, and right beside that you will see the issue identifier. So as we talked about in the previous lecture the S S P is the unique key off the project, and this would basically be the 14th issue created within that project. Now, this is the summary of the issue. So obviously you can customize this and make modifications, but this is written in a user story format. And just to be clear, this is one of the sample issues that was created by Gira when I created the sample project so you can ignore the contents for now. But typically, this is the summary of the issue or user story, and you can obviously change it and customize it at any point from this page itself. You've got some buttons here so you can edit the issue or details of the issue. You can comment on it. You can assign it someone, and these buttons here are basically transitions. So if you want to transition this issue from one status to another, these are the buttons that you would have to press just like I mentioned how transitions are represented as buttons on the issue details screen. So here you go. You can finally see what they look like now going into the details of the issue so this issue is ah, story. So it has the issue type of a story which you can also modify right here on the screen so you can change it to a bug or an epic or a task. The priority right now is set to medium, and you can change it. So, for example, we can set it to be the highest priority. Um, the effect version field. So what this represents is if this ticket affect any version that is already live, so an example would be you created a bug or you notice a bug and you created a ticket for it. Ah, and you know that that bug exists in a particular version of the software, so you can come in here and you can specify that yet this ticket or bug effects that version labels are something that you can, I guess group or identify tickets by. So, ah, you know, if you have a set of issues that all have one characteristic in common, then you can create a label to represent that, and then you can assign all those issues that label and you can go in and pretty much create any label you want. And I believe if I just type in the label, even if it doesn't exist, you can just select it and gear will create that label. And now you can use that label going forward for any other issues. The Sprint obviously tells you that this ticket is part of this sample sprint to, um if this ticket was sitting in the back log and not part of any sprint, then this field would not appear over here and the sprint would be empty. Basically, the status as we discussed is related very much to the workflow and right now, the statuses to do. If we take a look at the workflow for this issue, you'll see that this issue can have either of these three status is to do done or in progress. And the all with the arrow going into each one of these basically represents that you can transition into the each status from any other status. So all statuses can transition into in progress and done and to do, respectively. But when you create a ticket, it will always go to the to do status. So if so right now, this ticket is currently in to do. If I were to come here and click in progress, I am basically initiating a transition. The in progress transition, which will update the status two in progress. The resolution is basically a term that represents how a ticket can be closed. So right now, this ticket is under assault because it's still open. But if I go ahead and I mark this ticket as done, then the resolution would change to done. And I'm not going to update this ticket just yet. But I believe there are some tickets here that are already marked has done. And you can see here that the resolution is done and going to the next field here. Ah, the fixed version basically tells me that this ticket was done in this version and it was released in this version. So the difference between effects versions and fix versions is once again effects versions tells you that this ticket affected a particular version, whereas fixed version tells you that this ticket was implemented and I guess fixed in this particular version. So these are the details, the main details off the ticket. If you actually let me go back to the one that we were looking at before. So yeah, if you come back here, there's a description of the ticket in all tickets have descriptions, and obviously you can go in and you can edit it. And you've got some formatting tools here. Basic html type formatting tools. Um, so I'm just going to add, uh, some more text in here. I'm in the description so I can put that in, and I hit this check mark, which basically saves the description. I can add attachment so I can either browse for files on my computer or I can just drag from another screen into here, and it would all minute automatically upload that attachment at the bottom. Here, you've got a list of all these comments that you can click on comment here toe. Add another comment or you can do it up top. Um, you know, clicking up top will just take you to the bottom anyway. And let me just put in a comment. It's really that simple. Just click add, and it automatically adds it to the bottom. If you want to sort it where the newest one shows up on top, you can just click this air over here, and it's which is that sorting order? Ah, if you go to the all tab, this basically lists all the changes. Everything that has really happened with this ticket, it's pretty much a combination of comments and work log in history. So we what we talked about the comments tab. The work log basically shows all logged work, so Jiro has an ability to log work. If there's an estimate off four hours, for example, and a developer goes in and once toe or did two hours of work on a particular issue, they can go in and Law goes two hours and then it would show up here. Ah, history basically shows off shows a history of everything that was changed so you can see that I recently just made that description change, and I added this new line so you can take a look at that. Before that, I updated the status so that shows up here is well and clicking on activity is very similar to the history, but it's more of Leda laid out in a format like a new speed, and you can actually subscribe to an RSS RSS feed for this particular issue if you want to . So that's a summary of your activity that you can kind of monitor and see at the bottom of the ticket. Let's go back up for a second and look at the stuff over here on the right. So over here you can change the assigning. So like I mentioned, I am no longer logged in as an and men. I am another user. So what I can do is I can just assign this ticket to me and it updates the assigning to myself. And this is the user that I just created. Just as, for example, purposes, the reporter of the ticket was the administrator. Now, here you can vote for the issue. So this is just a means that juror has. You know, it's it's a cool feature for a bigger team. If they want to support development or ah, if they want to support the team or encourage the team to work on a particular issue, people can go in and they can just vote on the issue. And then, you know, the development team can always use this to determine what they're gonna work on next. So if they see a particular ticket with a lot of votes on there. It means that a lot of people really want that feature so they can go on, and they can put that at the top of their backlog. Watchers of a ticket basically represent all the people that would like to receive updates on that ticket. So right now there's only one watcher, and by clicking on the number, you can see that it's myself and the this account. This user basically got added as a watcher because that ah, the assigning field was automatically updated to them. So if anyone gets assigned the ticket, they automatically get added to the Watcher list. Now, if you have other members of the team, so right now this is assigned to the developer, for example. And if you want a que a member to be aware of this ticket and you know any updates that happen on this ticket, you want them to be notified, you can go in and you can add them as a watcher. And so every time a changes made to the stick it they would get an email notifying them of the change. Over here, you've got a couple of dates associated with the tickets. So when it was created and last updated, Um, since I just updated the description, it's showing that right here one minute ago. Ah, this is theology l section of the ticket basically showing that yet this is part of an active sprint which ends on the state, and you can click here to view the ticket on the board itself. So this is what you can see on the screen. Now, keep in mind that if you are seeing some new feels that aren't visible right now that you can see here or if some some of these fields are actually missing for you, there's a good chance that the Jiro administrator made modifications or customized what appears on the screen. So if there are any feels that you feel are missing or you want access to, you can always just contact your gear administrator and ask them if they can add it back on the screen. This is basically the view view issues screen Now up on the right over here. Just wanna quickly touch on this. So over here you can share this issue with someone, um, by either providing their user name or email address. You can export this issue in various formats, and over here you've got a lot of other functions that you can do. So as I was mentioning, you can log work. So by clicking here, you'll be able to log work. You could go to the ticket on the agile board. You can rank tickets Ah, which basically determine how its position in the backlogs of the high ranked tickets end up at the top of the backlog. You can attach files you can add or remove your vote. You can view all the voters, you can watch the issue. You can see all the watchers. You can create a sub task. Ah, or convert this ticket to a sub task. You can move this issue to a completely different project. You can also link this ticket to another ticket. So, for example, let me just go through that. So I clicked on link and you can see there are various options here, so you can see that this ticket, maybe blocking another ticket or this ticket is blocked by another ticket. So until that other ticket is complete, the developer won't really be able to move forward with this one. You could say that it clones another ticket. It's a duplicate. So, you know, usually if they're duplicate tickets created, one of them would usually get close. So you can use this as a reason for closing the ticket, insulin and so forth. So just is an example. Let's just say that this ticket blocks another ticket, So I'm just going to I can see at the bottom left over here. That S s P 13 is a bug, so I'm actually going to pick that one. So I'm gonna say SSP 13 is blocked by this one or this one blocks as a speed 13. So let me link these two tickets together and you'll see that for this one it automatically shows up here saying that this is blocking this ticket over here, and this ticket is a to do status. So let's go to SSB 13. And you can see now that this issue is blocked by this story. So this story is in progress. So ah, let me go into here and let me mark this as done. So once I market has done, the status gets updated to done. The resolution also got updated to done. And now, if I come back to SSP 13 any developer working on this would see that. Okay, this is blocked by this ticket, but this ticket is now done, so I could probably continue working on this ticket. So on and so forth. So these tickets, there are ways you can link them. Um, you can also call in this ticket. So if I wanted to Ah, if I have another issue that's very related to this one, I can just clone this one, and I can modify the summary if it I can clone all the links Aiken school in the spring value and create, and it would automatically create another ticket with all the details similar to this one. So let's quickly look at editing an issue. So if I click on edit, you basically see a pop up screen listing out all the fields that we've kind of already walked through. And let's just go through it quickly. So you've got the summary. You can change the issue type here. There are no components because there have been no components configured for this project. But if there were, Then it would show up here, and you would be able to select what component this issue would fall under. You can update the description specified the version that this would be going into the priority labels attachments. Ah, once again, you can link issues. You can update the assigned me. The epic link is basically, if this issue is under an epic, you can specify that. Um, yeah, this story or this bug should be going under the epic. Right now, there are no epics created, so nothing is showing up here. But if you were to go ahead and create an epic which just as a reminder, is a larger body of work which consists of multiple user stories, then you can go and you can specify that. Yet this user story falls under so and so epic, um, you can update the sprint. So if you don't feel that this ticket will be completed in the sprint, you can look and see if any. If there's any other sprints open Oh, are set for in the future, you can move them to that sprint. Or you could just completely remove it from the sprint. You know, that that is a more complicated process that will talk about when we're talking about agile boards. But yeah, in the last thing here is you can put in a comment just like you can do on the view screen itself. Now one another thing to keep in mind, just like the view screen. If you don't see some of these fields, it's probably because the Jura administrator configured it accordingly. But an interesting thing over here is you can see what feels should show up in what shouldn't. And in fact, if you don't really need to see all these feels every time you go to edit an issue, you can come in and you conduce to a custom field configuration and select which ones you want to see. So if you're only going to be updating the, uh, the assigning or comments, or you know you don't really need to see the epic link, for example, you can de select it. But I would imagine that having a description is something that you would want to see because it's fairly likely that you would be updating a description, similar thing to the summer. You would definitely want the summering on there. So just like that, you're able to create ah, custom configuration of what feels you want to see so that going forward, it just simplifies the edit screen for yourself and s so I'm just gonna go back and select all and again if you aren't seeing some feels that you think that you want to see or you should be seeing, Just talk to your junior administrator and you can ask them to add them to the screen. The last thing before I move on to the next lecture is I am currently in the issue, Navigator field or sorry in the issue Navigator screen. So I can click on different issues and look at the respective issue details. And over here in the top, right, there are different views for this page. So if I want a list view without wanting to look at the details, I can look at a list of all the issues. But I usually prefer the detail of you just so as I'm browsing the list of issues I can click in, view the details, but you can also click through on the issue I d here, and it'll open up those details in its own screen without the Navigator or the list of issues on the left side. So this would be the issue details, view, screen and, uh, yet that's pretty much it. I think we've covered everything on this screen. There is a lot out there, but I think the more you play around with it, the more you're going to get used to it. So now that we have gone through working on an issue, let's take a look at the agile boards and get into updating issues on the boards. 7. Working with Agile Boards: all right in this video, we are going to take a dive into the agile boards and era, and we're going to walk through how you can use them and navigate through the boards. So, as I mentioned before, I had created two projects, one for Scrum and one in Kambon and Jura automatically created a board for each of them. So let's take a look at the scrum board first. So when I select the scrum board, it automatically takes me to this sprint view, which basically shows me the Sprint scrum board. And the reason it took me to this page is because there is actually an ongoing sprint right now. So that's I guess the essence of agile is you work on these tickets through Sprint's, and whenever you have a sprint going on, that is the most important thing to kind of monitor and make sure it's on track. So this is the sprint view, and we've taken. We've seen examples of this in previous lectures, and so each of these cards, I guess, represent an issue, and it basically contains the summary. This little image or icon at the bottom left represents what issue type it is. So they use our sub tasks and this is a bug. And these over here are stories. The arrow beside that represents the priority. So it looks like all of the's are medium priority. And, uh yep, all of them are meeting priority. And then you've got the issue i d. And you've got the assigning. So in this case, this is assigned to the administrator, and this has no assigning whatsoever. Now, if you click on one of thes cards, it pops up on the on a pain on the right side with all the details of that issue. So you can see that this has no assigning. So signings blank or its unassigned and so on and so forth. So you would never have to leave this board view to look at details of any issue, which I think is eyes a good feature that gear implemented to kind of work on these boards . So a quick thing at the top over here. So you've obviously got the board name and then the name of the Sprint, and then you've got a couple of filters, so if you only wanted to look at issues that are assigned to you and how they're doing on the board. You can just click on this filter, which is the default filter made available by Gereb. And here it looks like there's only one ticket that's assigned to me and conveniently is already in the done state. So let me de select that. And let's look at the recently updated issues, so there's not a lot of issues, but again, it's self explanatory. These are all the tickets that were recently updated and is a good filter to look at the most recent changes that were done on the board. So what I'm going to do is now, let's assume that I'm a developer and I have a ticket that I need to work on. So I'm just going to take this sub task, and I am going to assign it to myself as I'm logged in as that developer user that I created and what I can do here is saying I have completed this task. I can move this from the in Progress column to the done column. So before I do that, we talked about how these columns represent, you know, our I guess the objective of a sprint is to move tickets from the left, most going to the right side. And in this case, we've got three columns we've got to do in progress and done. And in the last lecture when we were looking at the status is of this ticket, we noticed that there were also three. Status is to do in progress and done so conveniently. This is an example where the number of columns are exactly the same as the number of statuses. So the way this board is set up is that each column is mapped to the respective status. Now you can configure this toe, have one call a map to more than one status. And that's something we'll look at when we're talking about how to manage the's agile boards. But for now, it looks like it's a 1 to 1 mapping. So if I were to take this ticket and move it to the Done column, it is going to transfer the status of this ticket or transition the status of the stick it to the status that is mapped to the done column. So hence when I move it and place it there and marks that ticket as done and crosses it off . Now, I can also take tickets that are in the done. Call him back to to do or in progress. And ah, if you remember the when we were looking at the workflow for this ticket, you could basically move from any status to any other status. So that is why I am able to move it to any one of these columns. Now, some of the work flows might have restrictions where you know you can't move from done to to do. Then this board wouldn't let you drag it to this column over here. It would only let you drag it back to in progress. But obviously in this case, I can move it around toe pretty much any column that I want. So this is how developers can work on issues. They can look at details of the issue on the board, and they can update statuses and move them from left to right or pretty much dependent on what transitions are allowed for the workflow that is being used in this project. And this is the overall sprint view on the top. Right? You can see that there are five days remaining in the sprint and you can complete the sprint. So when you click on that, it will tell you that four issues were done and two were incomplete. And then you can complete that. And the issues that were incomplete will automatically be moved into the back. Look, now, obviously, this is something that the scrum master is likely to do as that person is the one monitoring the sprint and responsible for closing the sprint s. So I'm just going to cancel this for now. And that is a good segue. Way to talk about the backlog because obviously, how are sprints created? Howard, tickets put into a sprint. Ah, and that is from the backlog. So they're the backlog is managed through a completely different view and you can access these views from this left side pain over here. So this one is the current active sprints view, and then the one above that as the backlog. You a quick note on these other buttons over here so you can view the releases within this project. The if there any reports for the project, you can search for issues in the project and view the components that may have been configured for the project. So let's go to the backlog view. So this is the backlog of you. It basically groups the issues between the active sprints and the backlog. So here you can see the active Sprint that we were just looking at it through the sprint view, and you can see that there are six issues in the Sprint. You can edit the sprint to specify ah, name. Or even if there had been any changes to the start, an end date of that sprint, which are listed over here, you can look at the active team members that are engaged with Sprint. And then here are all the issues. So you've got the issue type. You've got the summary. You got the version that that issue is a part of the assigning the I D. And then the priority. And then the numbers over here represent the estimation for each of these tickets. So and it looks like Theis estimations are being done in the form of story points. So this ticket, for example, has an estimation of five story points. This one has none, and I'm guessing it's probably because this ticket is a buck, and it is difficult to provide estimations on bugs. Which is probably why Jura never put in an estimation for this one. So this is the Sprint, the current ongoing Sprint. And below that, you can see a back look Now, if you if the product owner wanted to start preparing for the next print, he could click on this and then start moving and dragging some of these issues into that sprint and as a product owner, If I was the product owner, it would be my responsibility to make sure that this backlog is fully groomed and the most important issues are on the top. And I could easily do that by just clicking and dragging issues around. So it's very easy to navigate, update and work on this board. And I think product owners pretty much live and breathe on this board and again, just like the spring view. You can click on any of these issues and you'll see the details of that issue on the right side. And another thing that you can view in the backlog view is versions and epics. So over here these are a list of versions that haven't been released yet. And if I click on version two, it will tell me or show me all the tickets that are part of that version. And it looks like these two tickets are currently in the Sprint and going to be part of the next version. But there are four tickets still sitting in the back log. Similar diversion three. There are two tickets sitting in the back log. And if you wanted to see issues that aren't really part of any release or haven't been planned for any release, you can just click on issues without versions. And as a product owner or the scrum master, they can start organizing if you know if they can squeeze some of these tickets into one of these versions now, in terms of epics right now, this project does not have any epics. So hence this column is empty. But if you have a larger body of work, you can create an epic to represent that create the stories that will go under that epic, and those stories will show up in this backlog view, and the epic would show up in the column, and you could pretty much select multiple stories by either selecting the controller shifty and dragging them into that epic. Similarly, you can drag tickets from here into the version. So if I wanted to take this ticket and say that, yeah, I'm gonna fit this into version two. I can just drag it all the way to version two. And now it will become part of version two and you can see that over here. So at the top, you've got your filters similar to the spring view. So if you click on that, you can look at issues that are assigned to you and again looking recently updated issues. And I just want to point out these numbers over here. This basically summarizes your estimations for the sprint. So the number in blue represents how much work that is still in the to do. Call him five represents how many are in progress, and nine represents how many are complete. So these numbers kind of give you, ah, quick idea of how that sprint is going. So that was a quick look at backlog and Sprint board for projects that are created as scrum projects. Now let's take a look at can been So if I select the sample can ban Project board, this is the can man board, and it looks very similar to the Sprint board, except for one big difference where the backlog is no longer there. And that's primarily because of the weak and Ben works. There is a backlog, and there are no sprints. It's basically a ah, a board to visualize the flow off work, and the goal is to ensure that there is smooth flow of tickets from the left to the right. Now, as we discussed before, you can see that this column is highlighted in red because it contains a work in progress. Limit, where you can really only have a maximum of one ticket in progress at any given time and because there are two tickets here. This columns highlighted in red so very similar to the Sprint board, a developer is able to update tickets on this can ban board by clicking and dragging them to any of the other columns. And once again, the columns that a ticket can go to is determined by the workflow. So let's take a quick look at the workflow associated with this can man project so similarly have selected a ticket and I convey you the details of that ticket here. So let's look at the workflow. So we've got four. Status is in this case, we got backlogs selected for development in progress and done. And you can see that anything can transition into each of these statuses so you can move from one status to any other status. And when you create a ticket, it goes into the backlog status. So here there are four columns, unlike the Sprint Board, where we had three columns, but conveniently, we also have four statuses. So it looks like this board has been set up where each column maps to the respective status and since Aiken transition from any satis to any other status. When I select this ticket, I can move it into any one of these columns. So if I move this, if I am the developer of this ticket and I've completed it and I move it to the done phase , it will automatically update the board and remove that alert in red. Because now I am satisfying the constraint of only having one ticket in progress. Now, another thing to keep in mind Something different in the way this board is set up is that you can see Ah, the tickets being grouped into everything else and expedited. And this is actually in the way that this board has been configured. And it's something that will visit in the section under leading an agile team because it's mostly going to be the manager, either the product owner or scrum master then manages these boards. And in this case, basically what has been set up is that all the tickets that our highest priority are grouped separately from all the other issues, and you can see that they have created what is called a swim lean and called it the expedite Swim lean, basically showing that these tickets are the highest priority and the development team should probably work on these first. So the goal would be to move these tickets up here all the way to done as soon as possible , since they are the highest priority. So this is a summary of the camera on board. It's pretty straightforward, very similar to the scrum board in terms of how you would be able to update tickets and move tickets from one column to another. And so we've taken a look at how you can work on issues and update issues through agile boards. Now let's talk about how you would go about creating an issue. 8. Creating Issues: there are a couple of ways that you can create an issue. If you are looking at the backlog view for a storm project, you'll notice here at the bottom of the backlog, there is a quick, create issue option where you can just type out thes summary of the issue you want to create. Hit enter, and it would create it for you. The only caveat to that is you can use this on Lee if you want to create that issue for this given project. More often than not, though, people usually would go here and click on Create over there. And this is where you can create an issue and you can specify what project you want to create it for, especially if you have more than one project or several projects. So everything else is fairly straightforward. And it's exactly similar to what we looked at when we reviewing the details of an issue so you can specify the issue Type a summary, the description components of their components available for the project and so on and so forth. Everything is fairly ah, if not exactly the same as what we saw when we were editing the issue. Now I remember noticing that there are no epics for the scrum project. So what I'm going to do is actually create an epic. Now, you noticed just now that as I selected Epic, the epic name Field came up and this was not visible when I had selected a story. So the epic name and there's a short description of what that is right here. It's a short name to identify the epic, so I'm just going to call this a sample epic and the summary I'm going to guess it could be the exact same thing. I'll just add sample epic summary at the end there and description pull Epic, uh, being created for the scrum project. I'm going to leave all the other items blank. Um, and over here you can see that you can't have an epic associated with another epic, So hence you can't pick an epic link. However, if you were creating a story, for example, you would be able to select if there if that story falls under a specific epic. So I'm just gonna go ahead and create this this issue. Now you'll notice that if you want to create multiple issues over here. All you have to do is select this and it will automatically ah of what? It would create the issue that you just filled out here. And it would display this form back again for you to create another one. So I'm going to do that and also similar to as we discussed before. Uh, this is where you can make a custom configuration if you don't want to see all feels every time you create an issue so you can modify this accordingly and again if you do not notice any of these fields on here But I would like of field on there. Ah, you can always talk to your gear administrator. And, ah, they would help you. Either They would be able to answer as to why you can't see the field or they be able to help you add it on there for you to use going forward. So I'm just going to select this and hit create. So it went ahead and created that epic with SSP 25 i d. And it kept me on the screen and you can see that it kept some of thehyperfix that had filled out pre filled. But what I'm going to do now is instead of an epic, I'm going to create a story. And I'm going to say, as a user, I want to create this story so that I can add it to the epic. And I don't really I mean, you can go in and put in any description you want just for the sake of putting something. I'm just copy and pasting the summary in there. I'm gonna keep everything else the same. No, in here. I'm gonna pick the epic ling, and you can see that it's displaying the epic that I just created. I'm going to select that and I'll uncheck this for no, and I'm gonna hit create. So now it's gonna update the backlog view, and you can see here under epics that that sample epic is showing up. And when I select it, you'll see that the story I just created is now in the backlog. So if I go back to all issues again, if I decide to add any other stories so say I wanted to I guess I had created this story. Um Prior. This is a quick story being created So it's just a test, a story that I created. I'm just going to add this to the sample epic as well, when there you go. So now you can see that even that is under the epic and so on and so forth. That is how you would create an issue. It's very simple. Um, the Quick way. Let's just do that again. This is a quick way of creating a an issue within this project, and here I can actually specify whether I wanted to be a bug or task. I'll just call it a task. For now, all I have to do is hit, enter, and there it gets added to the back look, and I can select this and I can move it into the sprint. But I'm not going to do that. That's something we'll talk about in the leading an agile team section. So that's how you would create a ticket. Now let's move on to the next video 9. Searching for Issues: Let's take a look at how you can search for issues. So if I go over here and click on search for issues, this basically means that I am starting a new search from scratch and you can see up. Here are a bunch of filter options that Geral already provides you. So if I wanted to look for all the issues under the sample scrum project, I can select that, and it basically filters out all the issues for just that project. I have more filtering options so I can filter by story or task by pick task. It's going to show me the task that I created in the last lecture. I can also do statuses or filtering based on status is who its assigned to and here has a lot more fields over here that you can go through. So, uh, it's a create date or, you know, looking for text within a description, um, or any stories that are associated with a particular epic name so on and so forth. There's a lot of options over here, um, and so just using the create date as an example, I can look at all issues that were created within the last day or week and or even between dates. So there's a lot you can do. What the's basic filters, that your offers you another way that you can search for something you know, not necessarily going into this search for issues Page. But up here in the navigation bar, Jura allows you to. So, as I clicked on it, jeers already suggesting various issues. And I'm assuming that these are issues that I visited most recently, so it's kind of a quick way to access issues that you visit very frequently. You can just just enable this or select the search bar, and you'll get a drop down of various suggestions Now. Cool thing the Jura has is that they actually have a smart search feature. So if I went ahead and typed, my and I hit enter, you'll see here that gear says, a smart, querying activated. And now you can run a search without the smart query if you just want to search for the word my either in the description or summary of issues. But the smart query that year did, was it. It displayed all the issues that are assigned to me to the user that's logged in, which is still that example developer, user that I created and some of the other examples are. If I just typed story, it will return all stories that have been created injera So similarly, there are many other smart quarry options that you can that you can type in here. And ah, Jura has some good documentation on them. I've provided a link in The resource is so feel free to take a look at that. Now let's go to the next video and let's talk about how we can do some advanced searching using Jake you well. 10. Advanced searching using JQL: Jura allows you to do searches by using these filters that they offer here. And they also allow you to do advanced searches through a query language, which they call Jake UL. It basically stands for Ghira query language. So let's take a look at how that works. So if I go ahead and I set up some filters, so let's ah, look for the scrum Project. Let's look for stories and let's look for issues that are either in to do or in progress. So it returns about 10 results, and if I click on advanced right now, you will see that General lays this out in a query language format. If you happen to be familiar with query languages such as Sequel, this would This would look quite familiar to you. So basically saying that the project equals SSP, which is the I D. And the issue type equals story, and the status is either in progress or to do so. You can search results or search for issues either using those pre defined filters. Or you can go in and build your own query to generate results that are more specific, and let me show you where this might come into play or have an advantage. So going back to the basic view where you can use these filters say, for example, this project had more than three issues say there were sorry, not issues. Statuses say there were more than 10 statuses. It happens to be a very complicated workflow, and there are 10 statuses, and the only status that marks a ticket is complete is the status of done. So you want to look at all issues that are not done. So what you would have to do is, if there is a total of 10 status is one of them is done. You would have to go in and you would have to select all the other nine. Status is just so you can view all issues that are not done, because over here there's no way of doing that. There's no way that you can just specify. I want to see all issues that are not done. No, you would have to go in and you would have to select all the status is that you want to see . So by switching to advanced, I can update this query that instead of saying all statuses that are in either in progress or to do. I can remove that. And Jura gives me options off how I can continue the query. So all I would need to do is, say, not equals and then hit space. And then gear gives me more suggestions, not equals, done. And I hit enter, and it gives me the exact same results. And so if I got rid of this entire query, I could start typing in general would give me suggestions. So if I wanted to populate that exact query again, so I would just go project. And there you go. So it's giving me some suggestions. You're so project equals. And then there you go. It lists out the projects available, so I'm gonna pick SSP, and it knows that I need to. I might be wanting to specify more parameters so I can spell, like, select and its base. And then it gives me more options here. So I'm going to look at issue yet I see issue type. So let's pick issue type equals. Let's see, what else? The offer. Yep. They're offering story and, uh, the status. Yep. There you go. And then I'm going to say not equals done. There you go. So it's really that easy. And I mean, it might take some time to get used to if you're not familiar with Corey languages, Um, some other examples over here. So let's try looking for the epic that I just created. So all I would need to do is epic is an issue type. So if I go issued type equals epic enter There you go. There is the epic that we just created. Now what if I wanted to look for all the stories in this epic so I could do, um when I created the story? If you remember, when I added the story to the epic, I had to fill out the field that was called the epic Link. So if I type epic Yeah, I see epic link over here so I can hit that and I can say equals and then their ego. It suggests the epic And if there were more than one epic, it would list them out and you could pick it, pick it from the list. So if I select that and hit enter, it will return the two stories that fell under that epic. So there's a lot of, um, cool things that you can do, And you can look up the documentation that Jiro has on Jakey. Well, Ah, and I have provided a link in the resource is now one more thing. Sorry. I'm just going to go back to the project. Actually, maybe there's a faster way it can do this. So I'm going to go back to sample Prada, the scrum project, and I'm gonna pick story and I'm going to pick in progress and done sorry in progress and to do so. This is what we started with. And you can see that I can switch to advance and I can switch back to basic. But if I switched to advanced, and if I change this to what I had before, so not equals done, you will see that Oh, I have to hit enter, so that it actually gives me the results. Now you will see that I can switch back to basic. And this is because Jeer tells me that the quarry is too complex to display in simple mode . So I guess this is the advantage. If there are things that you can't. Ah, search for using that simple query or simple filtering options of deer provides you. You can switch to advance and go about it this week. And once you've done a search and you've got your results, and if you notice that you're doing the same, search is over and over again. That's where filters come in so you can save filters. Now let's move on to the next video and talk about how you can say filters. 11. Search Filters: in this video, we're going to talk about how you can save filters. So if you've noticed yourself constantly going to the issue navigator and searching for the exact same types of issues, but every time going in and setting up your filters, then that would be pretty inefficient. So what you could do is you could save that search as a filter, and you can. All you have to do is just click on that filter, and it will display those exact same search results. So let me just make sure that I am starting a new search from scratch and let me pick the sample scrum project once again. And over here I'll just pick all standard issue types. Ah, and these are all these standard issue types listed. Could be a bug or epic story or task. And ah, you know, just like I did in the last lecture. I'm going to go in, and I'm just going to say And yep, and status is not equal to done now because I had selected standard issue types. You can see that Jake, you well has a function called standard issue types, and it's basically looking for the issue types that are in this function. So this function returns those four issue types. So it's a cool way of setting up various filters through the basic mechanism and then switching to advance. And you can see how generally is that out in Jake You'il. So if I hit enter, it will give me the results. And if I have a tendency of always coming in and searching for this exact same results, I could just save this as a filter. So I'm going to call this in incomplete issues in S S P. Yeah, makes sense. So me had submit. And now that gets saved over here under favorite filters. So if I go back to search for issues to start a new search, and if I click on this filter, it automatically sets it up because it's something that you can't set up in the basic format. That's why it had to switch to advance. And it populated the Jakey well, and it's displaying these issues. So if I actually marked one of these, as done, So let me look at this example one that I created, and I'm going to mark this ticket as done and even though it's displaying it here. If you had refresh so you can go down and had re fresh on these results over here, Or you can just click on this filter again and you notice that that issue is no longer gone . Before we had 14 but now we have 13 issues. So just a example of how the foot there's work, how you can save it and going forward, you can access the same results using those issues in ah, much quicker manner. And one thing to keep in mind is that going forward when you click on this issue, drop down just like it displays all the recent issues you visited. It will also display the recent filters that you've used, so it's another quick way of accessing that filter so you could just come in and you can click on incomplete issues and it will give you those results. So there you have it. That's a quick way of saving or setting up and saving filters for future use. Now let's move on to our next video, where we're going to go back to the dashboard and talk about how you can customize 12. Dashboard customization: in this lecture, we're going to create a custom dashboard. So Gear created a default system dashboard when we logged in for the first time, and they added two widgets. Or I think they actually call it gadgets and put them on the default dashboard. So let's try and create our own custom dashboard. No. So we can do that by going over here and clicking on Create dashboard, and we can call this my dashboard and you have the option of starting from the system dashboard. Or you can start from a completely blank dashboard and customize everything about it. You have the option of specifying it as a favorite or not, and you can also shared with anyone so it could be a group with injera. Or you could even do any user that logs in. Um, just remember, though, that if you do want to shared with anyone, just remember to hit add because sometimes people forget that they actually have to click on add. And then once you do that, it gets added to the to the list over here, so I can just delete that for now. And let's go ahead and created so dear creates a page like this. Now the first thing we can do is we can edit the layout. So in this case it displays these gadgets in two columns. So we can either have one column or we can have three columns. So let's just create it in the form of three columns for no. And then we can click on Add a new gadget. I'm just going to click it up here. It doesn't really matter. I think it creates the same thing. And ah, over here. Just because this is a new instance of Jared needs to load all the gadgets available. So if I click this, it will basically load all gadgets that it has to offer. And there's really a lot of, um so if I go into charts, So let's say that I want to add a chart and they've got descriptions for each and every one of them. So let's maybe look at a pie chart displays the matching issues for a project or filter as a pie chart. Okay, no problem. So we'll add this and let's go back up to Ajira and, uh, see if I scroll down. Yes, so I think I want to keep the assigned to me. They're gonna add that gadget on there. I'm also going to add favorite filters, so it's ah, quick way for me to access all my filters. Maybe I can add a filter results. So yeah, sure, Why not? Well, at that on there, let's go back up and look at wallboard options. So we'll look at Wal boards right at the end. It's kind of a cool way for you to project your dashboard onto a bigger screen for an entire team to maybe visualized. So we'll use the agile wallboard gadget as the example here, so we'll add that. And I think that's sufficient enough for now so we can close this now. All the boards have been added on to this page, but you would need to go in and configure each and every one of them, and you can move boards into a different column. So I'm just going to keep moving some of these boards up here to fill up the space. There you go. So we've got it. Looks like five widgets over here, so let's go ahead and now configure them one by one. So the agile board. Ah, let's use the escapee board, which is the can man board? Sure, Why not? Well, sure. That show the name. No need for quick filters. And we wanted to refresh maybe every hour. So we save that. And there you go. There is the can bend board right there. You can edit it through this, but you can view the status. Um, the filter results. So let's maybe pick one of the safe filter is the one that we just created. Ah will view 10 results, and we've got the issue type key summary priority. And I also want to add the status on there. So I do that in all select update every 15 minutes and save. And there you go. There is a quick look at my foot. The results. Favorite filters yet Let's I want them to show the issue counts. So if I had saved right now, I only have one filter that I created, which is under my favorites. And so it displays that, but the more filters you save, it will display all of them here. And it's telling me that there are 13 issues under that filter. Um, all issues assigned to me, so Yeah, let's just pick 10. I'm OK with the default settings here. I'll hit save. And there you go. There's only one issue assigned to me at the moment. The last thing is the pie chart. So we have to pick a filter here. So I guess I could just use these same filter. Ah, yeah. There you go. So it does recommend filters based on searching and select which type of statistic to display for this filter. So I'm just gonna go ahead and pick a signing share and hit save, and there you go. So the charts telling me that majority of the tickets are unassigned. One of them's assigned to the admin account and one or two of them to the admin account and one to myself. So there you go. There you have it. Now you can modify the layout as we go over here, because this wallboard does look a little, um, squished. So I'm going to go in and edit the layout, and I'm gonna specify this one where one of the columns essentially ends up taking the span of two columns. So there you go. So the wallboard looks a lot better or the agile Gore looks a lot better. The pie chart is expanded as well, and these look fine to me. So there you go. I just created a custom dashboard, and I added some widgets or gadgets that cater to me. And as a user of Ghira, you can go on and the world is essentially yours. You can go and take a look at all the different gadgets that you're offers, and you can customize them and position them according to whatever you're more accustomed to looking at every time you log into gear. The last thing I wanted to show you is a pretty cool feature that year has, which they call the wallboard. So if you click on view as wallboard, JIA sets up almost like a slide show, and they show all the different gadgets that you have on this dashboard. And the cool thing about this is you can connect this to a big screen. It could be a TV or just ah, big monitor that you have set up in the room that the entire team can view, and they can visualize what's going on. So if there are any metrics that applied to the team that the team wants always kind of monitor. You can set this up on a big screen that the entire room conceit E s Oh, they're always updated on the status of that metric that's relevant to them. So there you go. We've taken a look at dashboards. We've taken a look at a lot of things when it comes to working within an agile team. We're just going to touch on one more section that will review the overall navigation off Ghira as a user. And then we can close off the section. So let's move on to the last lecture of thes section. 13. Quick note on navigation & Summary of videos so far: before we end this section on working within an agile team. I wanted to take a moment and just mentioned a quick note on navigation. Once again. When we started this section, we went to the View All projects page, but we never ended up clicking in on any of the project. So let me go ahead and click on Sample Scrum Project and you'll notice that Ghira actually took me to the issue navigator. And the reason for this is because the ah, the last search that I did happened to filter the sample scrum project. And so what genera does is it will actually take me to the last relevant page that I had visited that was relevant to that project that I just clicked on in this case because I did a filter. Oh, are a search using a filter off the scrum project. It's taking me to that issue navigation page if I go ahead and I go to the sample of Scrum Board and I go back to projects and I go to view all projects and click on sample scrum project, it will now take me back to that sprint board because that was the last page relevant to the project that I had visited and you can see here that and we went through this briefly in one of the lectures is that these are all the basic project related pages, so I can expand that out just so we can see it a little better. So where we were before was under issues, and now it took us two active sprints. So similarly, the backlog releases reports, components. They're all related to the project page. So if we go back to the issues page, you notice at the top here that the filters are missing. That's because it's basically displaying to you the issues for that given project, since you happen to be under that project page. But if you wanted to see all those filtering options, you can click on, view all issues and filters here, and it will open up and display all those filters that you saw before, and you can do more custom searches. However, you notice that that project navigation on the left is no longer there, as you essentially opened it up to all projects because here I can go in and I can de select scrum and I can pick the Can Man project. And so it's no longer. This page is no longer related specifically to that project, and so you're no longer navigating within that project. But the moment I click on SSB 26 which belongs to the sample scrum project. So let me click that and open up this issue in its own details page. You'll see that we're back again to within that project, and so you will see all of those project relevant pages on this side over here. So there's a quick note on navigation in case you were moving around and you notice sometimes this pain and these options show up, and sometimes it doesn't. Ah, it's only because you are in a page that's relevant to only that project. So in this section we've looked at issues and their corresponding details. We looked at the agile boards and how you can update the boards while working on issues. We also went through searching and did some advance searches with Jake you well, and we learned how to save the frequent searches as filters. Lastly, we touched on how you can create custom dashboards and overall got a good look at the jury user interface and navigation flow. Now we're ready to take a step up and look at how we can manage agile projects by configuring and managing the agile boards and taking a deeper dive into how they work. 14. Configuring agile boards - Part 1 (Scrum board): in this video, we're going to talk about how you can configure agile boards. So let's start off by taking a look at our scrum board. So this is actually opening up the backlog of you. But you can also go to the board settings from here. Now they've got a couple other options here of just showing various panels. So if you hide a menu, it's just going to make the menu of the top collapse. And they've got the other panels, like we've seen in previous electricity versions and the ethics panel you can show or hide them. Um, something similar is available on the Sprint board, so you can either menu and you can also expend and collapse. Swim Leans, which will talk about one, were configuring the board. So let's just go to board settings so you can see here. There are multiple aspect of ways that you can configure the boards, so starting off with the general settings over here, you can obviously adjust the board name and, ah, just read what they have. Your the board filter determines which issues appear on the board. It could be based on one or more projects or custom, Jake, you Well, depending on your needs. So dear pretty much stole the words right out of my mouth. Eso coming back to here yet you can change the name of the board you can change. Who administers the board in this case, was the administrator of the ager Instance And you can obviously add more users if you would like to give them the ability to administer and make these changes here. Now, the filter is the main thing that determines what issues show up on the board. So in this case, when I created this crumb project, it automatically created the agile aboard the scrum board. And as a result, it automatically created the filter that the board will use to display the issues. And so this filter has its own query. So I'm just going to open up the query in a separate tab here. So it takes me to the issue navigator and it automatically sets up the filter. And the only filter being used is thesis ample scrum project. So basically, show me all the issues that are part of the samples from project, and that is what will appear on the gear aboard So if I go ahead and I modify this filters to say, I selected only standard issue types, so it'll only include these issue types, but not the sub task. And if we go back to the board for a quick second, you'll see that this story over here has to sub tasks. So let me select that and open up the details panel. And at the bottom you'll see two sub tasks. One of them is done, which is this one, and then this is the other one. So if I modify this filter by selecting only the standard issue types and I hit safe and if I go back to the board, those sub tasks are gone and so but you still see the story over here, and you can see that there are two sub tasks there, but it's just not showing up on the board. So let me go ahead and de select that again to open it up to all issue types. Save it back to the board and they're the Oregon. So that's an example of how the filter effects what issues show up on the board. Now. The shares determines who has access to the filter. So if you create a board and if that board is using a filter that is private, so only you are able to use that filter than you, only you would be able to see the board and no one else would be able to see the board. And this is a common issue that I have noticed people running into is that they create an agile board and they they let other people in the team. No, but those guys, they don't they can't see the board because in order for them to see the board, that filter that the board is using has to be shared or made public, or just, you know, given access to the other team members, whoever needs to have access to the board so I can do a quick walk through if this is well , so let me edit the filter share, and you can see that right now it is shared with anyone who has access to the scrum project , and right now I'm logged in as the jeer a administrator on Just keep in mind that if I was logged in as the other developer user, I wouldn't be able to make any of these config changes. So what I'm going to do here is I'm just going to delete this. So now it is not shared anymore. This filter is no longer shared. So if I hit Save and I actually have the other developer user logged in in a different browser over here, So here I'm logged in as the user, and if I so I already had the page open. But if I do a quick three fresh, you see that the board is no longer there. The scrum board is no longer there. The candy on board is still there, but this user doesn't have access to that scrum board. So let me go back to the administrator account, going to go back to the board and let's go back to the board settings and I'm going to edit this and add that share again. So I'm going to share it with the project. I wanted to be the scrum project and pretty much anyone with access to the project they're working on a project can share it. You have to remember to click ad so that it actually adds it on there and then save now if I go back to the other window. And if I had refresh there it is. Now the scrum board appears and the developer can start working on it again now also, one thing to note is that as we've talked about in previous lectures, you can see all your filters by going into the issues and manage filter section so you will see all the filters that have been set up on this page as well. So right now there are no favorite filters created by the administrator. But if I go back to the developers Page and I go to manage filters, if you remember from the previous lecture we had created a filter that only this user has access to. So it's a private filter for this user. You can see that here, but you can also see the other filters that are available injera. And because the scrum filter was shared with anyone who has access to the project, it is now showing up here so the Jiro administrator can go ahead and can make those same changes. The sharing changes on this page and it will also effect the same settings on the board that the board uses. So let's just go back to the board and back to the settings. And in fact, I'm just gonna open this up in a new tab so that we can keep the board open while we're making these changes in the settings. So we talked about the filter and how the board uses the filter and how the sharing permissions or privileges of the the filter effects. Who can see the board? This is the filter quarry. So right now it's just basic. The project equals thescore, um, project, and it's ordered by the rank in ascending order. And this just shows that the ranking is based on the rank, um, setting or rank field of the tickets. And this just tells you that the it is only one project that's part of this board, which is the scrum project. Now you can create agile boards that incorporates issues or displays issues from multiple projects, and we'll take a look at that later on. So let's take a look at the next settings over here, which is around the columns, and we've also talked about how tickets move from one. Call him to another and this is where you can configure it. So we've got it to do in progress and done. Call him. And what is in each of these columns are the status is so if you remember, there were three status Is that this particular project ah, used or had in its workflow. So each of these statuses convey, mapped to a different column by just clicking and dragging them. You can even move the columns around and order them in any way you want, and it just happens to be that these columns share the same name as the status. But I wanted to be clear that these columns are not the same thing as statuses. So I could rename this to not started. And I can rename this in progress to started. And if I go back to the board and I refresh it, you'll see that should have updated. Well, what's going on here? I thought I saved it, So let me just try that against us. Start not some nameless not started and make sure that stays and this has started. And let's say that should save automatically. There's no save button here, so if I go back and I refresh this. Okay, There you go. Yeah. So it's not started and started now, if I were to remove this done issue, for example, and move it to here, this is basically telling me that this status is not mapped to any column. So if the status is under the column, then all issues with that status will appear in that respective column. So because I've moved done out of this column, it is essentially unmapped. And when I go back to the board, you'll see that it automatically refreshed and done is no longer there because there are no statuses matter that column. So there's no point displaying the column. So now it's only showing me not started and started. And so if I go back to here now, say I moved the done status and I map it to the started column and what I'm gonna do is I'm going to rename this to started and for done. So if I say that and now I go back to my board so it on Mike Lee refresh and you can see that it renamed the Board, and now it's putting all the issues that are either in progress or done into the same column. And if I wanted to drag this ticket, for example, into this column, I'm given two options. I can either move it to the in progress status or the done status. So that's kind of how you can configure the columns and the boards. Injera. Ah, and so let me just set this back to how it was before. Um, an interesting thing that jeer offers is the set resolution check box. So if you want to check it off, um, basically, it means that by moving the ticket to this column, it's going to set the resolution to done so. Here. There's a little tool tip take to set the resolution to done when an issues transition to the status. So I don't want that Resolution remarked has done. If I'm moving into in progress, I only want that to happen when it's going into done. So that's how it's set up over here now, taking a quick look at column constraints. So over here right now, there are no constraints. But if I wanted to add a constraint, for example, I didn't want, so I'm going to select issue count, and what happens is that it automatically pops up these fields for each of the columns. And you can tell dear A that you don't want this column. So this should. This column should have a maximum of one ticket at all times. So if there's more than one ticket that hasn't been started, then you can have your flag that for you. So by setting this, let's go back here. So it reverted back to having the three columns. Right now, there's no problem, because there is only one ticket in this column. As you can see, there's a max off, one allowed. But if I were to move this one into this column, it automatically changes the background color of this column to read, basically flagging that this constraint is violated. So it's a cool feature, Bagheera, and this this is more so used in Can Van Format, and we'll look at it again where teams want to implement a work in progress limit. So I'm just gonna go back to having no constraint over here, and I'm going to change this back to in progress, and that's fine. I can see as is, and one more thing that you can do with configuring columns is you can add statuses. So, for example, if you don't see a status that you would like to map in this jail board, you can add it from here. Or you can also add columns. So, for example, I'm going to create a code review as an example column. And now what Europe gives you here is that it asks you to specify what category that column would fall under. So right now, Jerry gives you default of three categories, and I don't believe this is configurable, at least as of right now making this video this these categories, you can add new categories. It's kind of built right into Ajira, and what they represent is So, for example, the to do category represents any status that, uh, that, you know, it's related to an issue that hasn't been started. Or, you know, no one's really working on it, and it's kind of sitting in a pending state. So all those statuses would fall into the to do category in progress would be something that has started. So hence something like a code review would imply that the developments already been done, and now it's waiting for the court to be reviewed, so it's in progress. It's already been started, but it hasn't been completed yet, so it would fall under the in progress category. And then, obviously, something that's done implies that it's complete. No one really needs to work on the issue anymore, So any status or call him that relates to that kind of state of finish. You would fall into the done category. So for now, code review will just keep that in progress. And we'll add it over here and you can see that it automatically created a status for me called code review. But this code review status is not really part of the workflow, because in order for this, for this new status to factor into the workflow, you would need to go in and you would need to configure the workflow and that something will look in the administration section of this course. So right now there are no issues under code review. So if you take a look at the board, the column would appear. But there are no issues under that status. Sorry, it automatically refreshed, but I was too quick to hitting the refresh button there anyway. So that's how you can go in and you can add columns. Um, if you don't want to map this status to any issue and go back to the board, that column would disappear. So that's how you can add new columns. And you can map statuses to the columns, and you can provide constraints to the columns. So we've taken a quick look. Well, I guess we've taken a pretty detailed look at how you can modify the general settings in the columns. Let's continue in the next video and take a look at the other options or other ways and other things that you can configure for these agile boards. 15. Configuring agile boards - Part 2 (Scrum board continued): All right, let's take a look at some of the other ways that you can configure natural board. So we talked about the general filter settings, and we've talked about configuring columns. Next thing would be some lanes. So what are swim Leans? It is basically a row on the board that is used to group issues. So right now the swim lane is set up to be based on stories. So if you look over here, you can see that this story has sub task. So it kind of has its own swim lean, and there are all the other stories only have sub tasks, so they kind of just appear one on their own. But if I were to go in and I would change the swindling to assign E and you'll see okay, so the unassigned issues which show up below the other civilians. So let's take a look and see how that board changes. Think I have to do a refresh on this, so let's go ahead and refresh the board. Now you'll see that there are swim lanes for each user, so I know there's a developer. There's the administrator account, and then there is unassigned, and you can go over here and you can collapse. Also, millions to kind of see Okay, these are all the some leans available on this board right now, and you can expand all of them to see All right, there's only two issues that were assigned to this user, but they're all done. It looks like the administrator has a couple of issues that he needs to work on. And then there are a couple issues that were complete but not really assigned right now, and that's how you would organize it. So I'm going back to the settings. You can create some lanes for epics for projects, or you could have no soon Leon's whatsoever. And if you go back to the board and do a quick re fresh, it just displays the ticket sizes so and you can see that the sub tasks appear on their own , and it just shows over here that this is part of a user story, and this is the subtext that's part of this, the same user story. So going back here, you can create your custom, certainly, and as well based on inquiry, and this is something that will actually look at when we're going through the settings for the can ban board. Um, if you remember that there was an expedites family that was created, so we'll take a look at it over there. Let's move on to quick filters. So over here, going back to the board quickly. So you know what? I'm just gonna go back to some lanes and I'm going to change it back to the way it was, which is stories. All right, so let's do a quick refresher on this. All right? Now, in terms of quick foot, there's you can see that Ghira automatically created to off them my issues and recently updated, and you can see that. Okay, my issues are assigning equals the current user, which is the user logged in. And there's a short description off that filter and recently updated, basically is updated. Date is greater or equal to within the last day, so you can go in and you can create your own quick filters. So, for example, let's look at thehyperfix authority tickets and you can say so. This is where you start typing in your J QL query so it will give me the suggestions of priority. And instead of saying or unless his try equals and then it should give me the suggestions, I'm going to say highest, and I'm going to just say display highest priority issues. And I'm going to add that on here now. If I go back to the board and do another refresh, you'll see that there is that new quick filter that's been added. And if I select it, it'll filter based on those issues. Right now, it looks like there are no issues that our highest priority. So let me look at this one and update the priority to highest Say that. And now click on the high priority filter. And there it is. So it's a quick way or easy way off. Um, setting up quick filters for the board itself, and you can customize them any which way. Ah, using Jake you. Well, all right. So moving on card colors. So this is another cool thing about gear, uh, era that they allow you to visualize the board in that you can highlight some of thes cards based on a common characteristic with the same color. So if I go over here and I say colors are based on priorities. For example, Ah, it list out all the high, all the different priorities. And I can say that, yeah, highest it should be read. Makes sense. I can change the color to be something more brighter, Um, or moving up the top here doesn't really matter. And then something that's medium. For example. I could specify that to be green, and if so, it automatically saves and let me do a quick re fresh. And you'll see now that these issues have this vertical colored line on the left side of it , and that basically represents, you know, you obviously, as a manager of the board and as a team working on the board, you would know you would be told how the colors have been configured. So it's a quick way to visualize. After annoying how what the colors represent. It's a quick way to visualize what the priorities are now. Priority may not be the best example, because you already have errors over here that kind of indicated, so you can ah, you can go in, and once again you can provide your own custom query so you could even use an assigning. So everything that's assigned to yourself or another user, you can specify a different color for that person. So I'm going to go back here and I'm going to use this a sign e equals current user. And I'm going to do exactly that. So I'll paste that into here. And I'm going to mark this as, ah kind of yellowish color. Sure, let's just go with that one and let me refresh the board. So I'm logged in as an administrator, and so it didn't look like it worked. So let's take a look at that and see what happened. Oh, I need to click. Add here. So it's a common mistake. Sometimes it saves automatically. Sometimes you have to click in at button to actually add it on there. So now let's go back and refresh, and there you go. So if I am a logged in user and I set up that query, um, and obviously, if I'm a developer and I'm not able to configure the board, you can always go and ask your gear, a administrator or even the board administrator to go ahead and put in that kind of a color query filter And so then you can go in and you can see you can easily see the tickets that are assigned to you. So that's a cool way of setting up your card colors. Okay, for the card lee out, this basically means that for each car that you have over here, Jiro lets you provide three extra feels that you can display over here. So right now, if you want it to look at details of each of these cards, you would need to click on them. And you will need to look at the specific detail that you're looking for if it's already not displayed on the card itself. So, for example, a priority and the issue type, you can see. But, for example, the labels you can't see. So let me select this one and give it a label of test, for example. And what, once again, jury, if I just type a label, if it doesn't exist, it'll just create one for me. And I'll save that and let me select this one as well and give it Ah, give it the same label. Yep. So it suggests that that label was already created. So there you also have given these two issues a label. And if I go on over here and so there are two views, one is the backlog in the active sprint. So I'm gonna go in here and I'm going to pick the labels field, and I'm going to add that on here. So what that does is now it displays the label over here right on the card, so you don't have to select the card to view the details and find out what label it is. It's automatically shown on the cart, and you can see that this one and this one as we set up our showing test. So jury allows you to display at least three fields on the card, So it's kind of a cool thing. If there's something about each of these issues that's important to know, and you'd like to see it at a first glance instead of clicking on each of the issues to view it, then you can go in and you can add it over here. Now the same thing would apply to the backlog. So let's just go to the backlog of you for a quick second here and you'll see that right now it shows the version number and nothing else. So let's see what happens if we add the label here as well. So for backlog at the label, click Add. Now, if we go back here, just gonna do a quick re fresh. Yep, so the label actually got added at the bottom over here, so you can see that these two have that label of test so similar to the Sprint view. These cards on the backlog of you can also show up to three of those fields any any feel that you want to display that you can select from this drop down. So that's another cool feature about these address boards. Let's move on to estimation. So estimation basically represents how the development team are able to estimate or what is the estimation based off of. So right now we see that the board is based off of story points, and you can change that to be original time estimate, which changes that to estimation based on hours or weeks or or days in terms of you know how long the development team would think they would be able to complete a particular ticket and the time tracking option over here basically means that if the if any developer goes and in logs hours than whatever they log will go against the remaining estimate. So what this says here, so tracking time against issues using gears, remaining estimate and time spent feels so It basically, uh, sets it up so that the estimated field links up to the remaining time. So if the estimations been given for four hours for a particular issue and the developer goes in and logs two hours of work than the remaining estimate automatically updates to two hours, so I would recommend selecting that so that things kind of update as the developers going in the log work and another thing over here with the boards, you can specify working days, so usually, obviously, you'll pick Monday to Friday. If there any holidays coming up, then you can add those dates specifically, and this may or may not be used as often, but this primarily comes in handy when you're doing reports. Eso to look at how much a team was able to achieved in order to calculate the velocity. If you had a couple of days of holidays, you know public holidays during that sprint, it's worthwhile to put it in here so that it doesn't affect the report at the end of that Sprint because obviously developers had fewer number of hours available in that sprint to work on the issues. And finally, the issue Detailed view basically specifies what items would show up in the issue detailed you. So let's take a look. Um, let's take a look over here and go back to the oh are you could view it here as well. So notice how there's status priority components labels and when you come back here, its status priority components labels. So what this allows you to do is it allows you to configure how feels display in the details pane while you're viewing the board. So if I move the labels to the top and priority to above status and I go in here and I do a quick refresh, you'll see that it's now displaying the labels first and then the priority and then the status so you can go in and you can add additional fields so you can add the rank if you want. Um, then below that is the date field section and then people and then links. So just like that, you've got the people you've got dates s so on and so forth. So this basically allows you to configure this details panel whenever you click on one of these cards, and that brings us to the end of configuring board. So obviously there's a lot in here and feel free to play around. This is probably something that only administrators or administrators or the project or the board would have access to. As a general developer, you may not be able to go in and actually configure these boards, but obviously, if there's something that you want done, you can always reach out to the board administrator and asked them to put that in. But there's a lot of capabilities here, adding quick felt there is changing the card colors or the card layouts, adding swim lanes, modifying the columns. And obviously it all starts off with the main filter that the board uses. So this is us walking through the scrum board. The Can Bend board actually happens to be quite similar, but let's take a couple of quick minutes and just go over them. In case we see something that's different, it would be worth walking through it 16. Configuring agile boards - Part 3 (Kanban board): we spent a couple of lectures walking through how we would configure an agile board, in particular a scrum board. So now let's take a look at the camp and board. So we have seen this board before, and we see how similar it looks to a scrum board. And before we dive into the board settings, we can already almost make guesses as to how this board has been set up So we can see that there are four columns and we'll take a look in just a bit to see what statuses are mapped to. Those columns we see to swim lanes configured over here so we'll take a look and see how those swim lanes have been configured. We also see the default quick filters that are set up, and there are no custom quick filters. But pretty much all the functionality, as we had seen on the scrum board, is also available on the can ban board. So ah, yeah, and also just one more note is that we see there's a constraint over here for this column to allow only a maximum of one ticket to be in this column. So let's go in and I'm going to open up the board settings in different time here, and you can see that the options or various things that you can customize are pretty much exactly the same as on a scrum board. So we'll not go into all of these in detail S. So if you're looking for just managing a Can Bend board and haven't had a chance to look at the previous lectures where we went through the scrum board, I would recommend going through that as we went into, ah, lot of detail for each and every one of these options. So we're not going to be doing that in this lecture. So feel free to view that if you have not already seen those lectures on the scrum board, so you've got the board named the administrators. The filter determines what shows up on this board, and the shares determine who can actually see this board or, in other words, who has access to use that filter that is used by the board. This is the filter query, so it's pretty basic to show all the issues in the escapee project, the can Man project, and obviously there's only one board being used. Sorry, one project being used in this board. Now, this thing at the bottom here, this is new. So we never saw this in the scrum board. And what this is is a can bend board sub filter, so it basically filters issues for unreleased work. So let's go back to the Can Van board over here and just a quick reminder on how can ban works. There are no sprints, and basically tickets move from left to right as developers work on them. And once a set of tickets are done, you can generate a release that would comprise off all the tickets that air done at that time. And you would be able to do that by doing it from here. So basically what that board setting allows you to do is it allows you to filter the unreleased issues and basically ensuring that Onley the unreleased issues end up appearing on the board. Because if you all also have the released issues show up on the board than this done column would just keep growing and growing and growing, and issues would basically never disappear or never leave this board. So you definitely want issues that are complete and released to no longer be visible here because you're no longer really working on them. But those issues that are released will always appear in the reports. Um, and that's that's a completely separate thing altogether. So that is the purpose of this sub filter. Let's move on to columns. So as we had predicted, there are four columns, and it looks like based on the workflow, there are four statuses, so each status is mapped to its own column. We can see here that they have a constraint for issue count. So the number of issues that are permitted to be in each of these columns, the only column that has a constraint, is in progress. And this is where they have specified that only a maximum of one issue is allowed in that column. And you can also see that they have set the resolution to update to being done whenever a ticket moves into the done calm. Now, one more new thing for this can Ben Agile board management is this. Can Van backlog now? We had talked about scrum having a backlog and a sprint view, However, can Ban does not have any sprints. So all it really has is three board view. There is no backlog for can been. However, Jura added this feature where if you go back to the Can man board and say you're working off of can Ban and there are a lot of tickets that keep getting added to the backlog, eventually this would become unmanageable to view on a board like this. So what gear allows you to do now is you can create a backlog of you for a can ban based project. So if we take this backlog status, and if we move it to this can van backlog, what happens is there's a little option that shows up here, and we'll take a look at that in a second. But let me go back to the board. So obviously that column disappeared because there's no longer any status that's map to that column. But if I go ahead and I refresh this page, you will see that now there's a backlog view, and when I go there, it lists out all those tickets that were in the backlog status, and this looks exactly like the backlog view in a scrum format and So you've got a backlog and you've got the selected for development status here, and this is kind of where you can organize your tickets. And it's a more easier way to view issues that are in the backlog, especially if that backlog keeps growing. So as you manage the backlog, you can move tickets into the selected for development, and then the developers can work off the board. It's more manageable and easier to look at. You don't have to keep scrolling down because there are a lot of issues piling up in the backlog, and now they can start going in and updating the issues that are basically selected for development. So this is a very cool feature that Jura has made available and going back to this epics panel option. This appeared the moment I switched the backlog status to into the Cambone backlog. What this basically means is, if you remember, when we were looking at the backlog view for the agile scrum board, you were able to open up an ethics panel over here. So that's pretty much. What this means is that you want to display the epics in its own panel or do you want it to appear as an issue by itself within the backlog. So if you want it to be just like the scrum board, you can just enable that. And it'll appear just like it does on the scrum board. So there's something different. Everything else is kind of similar. You can drag and move columns around. You can add a status that hasn't been mapped or doesn't appear over here. You can add additional columns, and you can drag statuses and map them to various columns. So let's move on when locate some lanes. So as we noticed in the sprint board, they have to swim leans. So if I go ahead, you just close that if I go ahead and collapse all the swimmingly and so there are to expedite and everything else. So what do they have here? So for expedite, they've basically specified that the priority is highest, so all issues with the highest priority will have its own swim lane. So, from a development standpoint of Oprah's can see that if there are higher priority tickets work on them first, so let's have them visible at the top, so it's much more easier to see so we can go in and we can add a, um you know, fairly urgent swimming. And this time we'll say that the priority equals hi. And let's call this all issues with high priority. Let's add that on there. And now if we go back to the board and let's refresh it. So right now, there may not be any tickets with a high priority. But if I were to take this one and let's change the priority to high save that, maybe we need to do another refresh. There you go. So right now, fairly urgent is showing up at the top. If we want that to be a the bottom, then we can move, Expedite up there. Go back to the board Fresh again. There you go. So you've got the expedited timeline all the way at the top. This is for the most urgent items you got the fairly urgent items below that and then everything else after that. So another example in way you can configure, swim leans. You've got quick filters, which is exactly the same as what we saw in the scrum board. You can add your own quick filters to show up at the top here, using Jakey. Well, you can configure your card colors just like on the scrum board. So ah, for this one, let's just set priorities and we can leave the default color selected for the priorities if you go in and if we update it, it's just an additional color to visualize and look at the things that require attention. And then you've got your card layout. So, as we have discussed, you can display up to three feels on these boards, something that might be of interest for you that you want to see. Uh, right when you're looking at the board rather than having to click on each card to display it in the details view. And then you've got your working days which more so is for report generation. If there are any holidays or non working days coming up, then you can go in and you cannot that here and finally going back to the issue details panel. Over here, you can modify and configure what feels you want to show up and how they're ordered by moving these up and down. So overall it is fairly similar, if not pretty much almost exactly equal to the scrum board and how you can configure a scrum board. But there are some subtle changes in subtle additions for Can Bend board configuration such as these sub filter and also the option to utilize a can ban backlog if you've got a lot of tickets that are adding up into the back, look. So there you go. We have taken a look at how you can configure agile boards, both scrum and kambon. 17. Creating projects: In the last few lectures, we looked at how you would configure agile boards and as an agile team lead. That's definitely something that you would be doing to help your development team visualize and work on those boards. But what else would you be doing as a team lead? So whether you are a project manager or product owner or scrum master, you would probably have the role of or the responsibility of grooming the backlog. Setting up. Sprint's helping the team create the Sprint Baghlan backlog, starting the sprints, monitoring the progress, closing the Sprint, creating versions to track thes software releases and looking at reports at the end of it now. So what I'm going to do for the rest of this section is I'm going to pretty much start from scratch. And, ah, what that entails is creating my own project. Eso. If you're working within a small team or a smaller team, there's a chance that as an agile lead or the product manager, you will probably also have administration privileges and not something that gear requires to be able to create projects so you would have to be a user that has administration privileges Now, if you're part of a bigger team or a bigger organization, then there's there's a chance that there's a dedicated your administrator, and you, as a project manager, may not have those administration rights. So in order to create a project ah, project that you would be working on or managing, you would probably have to reach out to the administrator to help you do that. But I'm going to assume that were part of a small team. And as you being a agile team leader, you also have administration privileges. And so you're able to create a project. And what I'm gonna do is the product of the project that I'll be creating will actually represent this very course, and I will use it for the remainder of the section as well as the course. So what I'm gonna do is I'm gonna create Ajira course project, and I'm going to set it up as a scrum project and then going to create epics to represent each of the sections in the course. And then I'm going to put in stories within each of those epics to represent each lecture or video in the course. And as I go through each of these sections or the remainder of the course. I'm going to start a sprint for each section, and I'm going to close that sprint when I'm done that section. So as I'm walking you through the remainder of the course, I'll be using and updating this project as we go. So let's get started. I'm going to now create a new project, and you can see here that obviously the reason I'm able to even create a project is because I'm logged in as the administrator. So here you have various options. So what kind of project would you like to create a scrum? Or can ban or just basic software development? Or perhaps it's a business related project. So let's take a look at some of these Justus example. So if I pick Scrum and I hit next, it tells me that the default workflow that's going to be assigned to the project comprises of these three statuses, and these are the issue types that will be incorporated into the project. So obviously, having stories and epics are essential to a scrum based software development project. So let me go back. Look, let's look at the can ban format. So here, just like we saw before For the sample project, you've got four statuses in the workflow, and you've also got these issue types and story and epic is also included. If we go back in, select the basic software development project. So you've got a different side of status is you've got from to do doing progress too in review and then done and looks like we don't have stories here, but we do have epics, which is a little confusing, but oh, well, we're not going to be using this anyway. And, ah, let's just take a look at some of the business ones as well. So it looks like a basic project management project just involves the basic to do in progress and done. And you just have tasks in sub tasks to deal with. And a task management, for example, would just be to do and done so. It's fairly straightforward. So as I mentioned, we're going to be treating this project as a scrum project. And also this is what I used create sample data. This is where jeer allows you to create sample projects with sample data. Ben, you can also import a project from an external source. So that's it next, and we see that this is the workflow that's going to be assigned to the project and year we can put in a project name, so I'm going to say dear, of course, and you can see that Jiro automatically suggests a unique key for that course. And I think there is a limit you can specify or update this any key you want. So if you want to add a P at the end, so JEH records project, I think there's a limit yet. So there's a limit of 10 characters, so you can provide anything you want, as long as it's unique with injera. So, for example, the other project that we have the scrum project had the SSP key. And if I tap out of that you see Jiro one. I mean create or use this key because it's already being used by another project. So I'm gonna keep things as using J. C and eso Aiken be the project lead that's on a problem and just confirming that it's going to be of type scrum and I'll hit, submit and Era is going to create that project for me and automatically takes me to the backlog view. And obviously that means that a board was created for this project, which you can see over here. So there is the J. C board. So if we go there actually were already there right now, we're looking at the backlog view. And so right now there's no tickets. There's no issues been created for this project. It's completely brand new. We can go into the board settings and just administer and configure that board and just make sure everything's the way you want it to be. So, for my sake, I'll leave the name as is over here. I'm okay with all the default. I'm OK with the filter Corey up. So I want to show all the issues that are part of the JC project. And so everything here looks good to me. Let's go to columns. I don't need to put in any constraint what I'm gonna do here, though, is that because I'm going to be representing each video as a story. And basically, when I start a lecture, I'm going to Ah, that that lecture that use the story is going to be in the to do column and then when I complete it, I'm just gonna market has done I'm not really going to be using the in progress. Call him. So what I'm gonna do is I'm going to remove the status and keep it as an unmapped status, so that will update the board. And I just opened that in a new tab. And if I go to the spring view, it's just gonna have to columns to do and done So that is, I think all I would need to do for mapping out or configuring the columns. Let me go to swim, Leans. I don't think I really need any soon lanes. Um, but perhaps, you know, just for the sake of it, I'll just select epics and see what that looks like. I don't need any quick filters or card colors, so I'll just leave everything as per the default setting, and that's pretty much it. So I'll go back to the board. And so right now there's no tickets and no sprints created. So the next step for me would be to start creating issues, whether it's an epic or story. So let's do that in the next lecture 18. Creating epics and stories: All right, so in this lecture, we're going to be creating some issues, namely epics and stories. So let's go right ahead and create an issue. And I wanted to be in the Jura course project and the first couple that I'm gonna make would be epics. So let's provide an epic name, and here I already have an example. So leading an agile team is this section that we're covering. So I'm gonna call the epic name exactly that. And for the summary. I'll just put in the same thing and I'll upend it with using Jura. I don't really need to put in a description for that. So that's good. And I'm going to create another epic and this one I'm going to call it the GE Era administration section, which is going to be the section that we cover after this one, and I'm going to call. This doesn't really have to be different from the epic name. The summary can be the same as the epic name, but I'm just going to add section to that and let's just create these two epics for now and see how they show up on the board. So obviously nothing really happened. That's because epics don't show up on the board as those individual cards. They show up on the panel over here. So here you can see the two epics that we just created, and you can view the details right now. There are no issues on any of them. And so let's go ahead and create some stories so quick, create again. And this time I'm going to select a story and, uh, let's see. So the first thing going to do is, as a user, I want to learn how to configure job boards so that I can leave and agile team. So this is a video that we covered earlier in the section, and I'm just going to leave. Everything else as is, will create another quick user story. And as a user, I want to create user stories to populate the backlog. Actually, before that, I want to create a project, and that's what we did in the last lecture. So I want to create a project to manage this course, so I'm going to stop there and let's see what that looks like. So now we've got these two stories in the backlog and what I want to do. Actually, what I could have done is while I was creating them. So let me go into the details of this issue. I just opened that up in a new tab, and, uh, what I'm gonna do is I'm gonna edit this and I could have done this when I was creating the issue, but I could have provided an epic link. And now you can see that it's suggesting to me all the epics that are available and so these two are the epics that we just created. And this is going to go into the leading, an agile team epic. So I hit update. So it adds, it's now displays the epic link Feel over there. I can close this and let me close this tab. Go back to here, had refresh. And now you can see that it shows the story as being under that epic. Now noticed the color How it's has a brown color to it. I can change that color over here If I go to the epic and change that to Green. This now shows up as green. Now I can also assign stories to epics on the board itself by clicking and dragging it into there. So I want this story to also be under this epic so I can just do that and it updates that story accordingly. So for the remainder of the issues that I'm gonna create, I don't really want to be creating them in story form. I just did that to show you as an example. But what I can do is I can just create the rest of them as tasks. So the task that we're actually doing right now is create user stories to populate the backlog. Uh, Then what we're gonna be doing next is we're going to groom the backlog and set up sprints . And then once we set up the sprints, we also want to make sure that as a product owner, we want to set up software versions. And then finally, as I just give it a moment to update, we're going to close a sprint and look at reports. So these air a couple of quick ways that you can create stories or tasks or epics, and you can select multiple issues in the backlog and dragged them into an epic and all of them will end up updating to being under that epic. Ah, I'm not creating any stories or issues for Ajira administration. That's something I'll do later on. And in fact, I'm just going to take a moment and I'm going to think about other topics or other videos that I want to include in this lecture or sorry in the section. But I'm not going to do that right now. I'm sure you don't want to be spending your time just looking at me, typing up in creating various tasks and issues. So I'm going toe stop this video. I'm going to think through what other topics I want to cover in this section. I'm going to create specific tasks to represent them. And let's just move on to the next video where we're gonna have a backlog set up with a bunch of stories. We can now groom them and create a spring backlog and start that sprint 19. Starting sprints and working on sprints: in this video, we are going to go ahead and groom the backlog, set up a sprint backlog and ultimately stark our first sprint. So over here I have a couple of user stories and tasks set up in the back look. So in order for me as a product owner to create a sprint backlog, I can go ahead and click on create Sprint, and that creates this first empty sprint over here. And I can edit that and change the name if I want to. But I'll leave things as is, and what I can do is now I can select the issues that I want to include in that sprint. So right now, I'm just going to include all the lectures that are part of this section. And so now that I've moved them in the sprint, they appear here now also, one thing you notice is that the story has this estimate field, but the tasks do not. And this is one thing that I actually forgot to do as I was configuring the board. So what I'm gonna do is I'm gonna go back to the board settings and I'm going to look at the estimation settings, and I'm going to change this from story points to original time estimate. Now, if you remember, there are two ways that you can do estimates. Now, over here, Jiro also allows you to do ah or use issue counts. But I have actually not used this before. So Ah, this is something that maybe you can do some trial and error with your team to see if this is how you would like to provide estimates. But more often than not, I stick to original time estimates where the development team can go in and provide their estimates in the form of hours or days. So basic time intervals. That's more easy to visualize in track. And I'm also going to select this so that the remaining estimate work gets updated as and when tickets or work gets logged, I'm going to leave that and go back to the board, and now you should see that I am able to provide estimates for every single ticket. So how would you go about doing that? So assume now that the spring backlog has been populated by the product owner now you would have the sprint planning meeting and you would go in and talk about each of these issues that you're targeting toe work on during the sprint and put in your estimates. So if you click on each one of them, you've got your estimate field, and obviously so I'll just put in rough estimates for now, just as an example. And I have some pre populated ones here just cause I've been using geo for so long that it saved all my entries. And so let me put in one hour for this, and it automatically updates the remaining time because you haven't started the sprint. So obviously that means you haven't started working on this issue. So whatever you estimate right now would be what is remaining for that ticket. So let me go in and provide some more estimates for these other issues here, and you'll see that at the bottom. It tells me that there are eight issues in the sprint and the total estimated time for development right now as five hours, which is four plus one So I can go in there and I can also if if I think you know a particular item is gonna be really quick, I can go in and put in 15 m to represent 15 minutes hit, enter. And that populates. That's no, I've got five hours. Five minutes? Um, I could even put in a day so one d would represent one day. So now I've added 11 day, five hours, 15 minutes, So on and so forth. So let me just go in and put in some random values in here just for example, purposes. And also, if you put in 30 for example, without any unit at the end of it and you hit, select or you hit enter, so it automatically puts in 30 minutes. So that means the default unit for any estimations has been set two minutes and that can be changed in the administration section. If you want the default, for example, to the hours, you can obviously go in and you can update that. So let's just go in and provide a quick estimate for the last one. And I want us to round up to a good numbers. I'm gonna put in 45 minutes. Here it enter. So we've got two days in one hour. All right. Interesting. So we've provided estimates we've decided that this is all doable within the Sprint. And so now what we're gonna do is we're going to start the sprint. So when we go in and click start so it confirms that this is the spring name. It gives you some options of how long you want to sprint to be. You can even provide a custom duration and pick thes specific dates that you want. For now, I'll just keep it to one week and you can type in a sprint goal if you would like and you had start and yet start it automatically takes you to the sprint board. And now you've got an active sprint going. And so now the development team con's start working on tickets one by one. Obviously, this is the board that I created just for simplicity sake. It's There's only two columns, and obviously we've already talked about configuring agile board, so I'm just gonna mark that is done. We have also created a project. We have also created user stories to populate the backlog and this lecture that were talking about or we're in right now. We're basically grooming the backlog, which we've done, and we have set up a sprint and we have started it. So obviously I'm paying no attention to these estimates. I only provided these estimates, for example, purposes. So let me go in and drag these three to the done column. Now let's go back to the backlog view. And what you see here is that we've got three hours, 45 minutes of work still in the to do column, and we've completed a day five hours by and 15 minutes worth off work. So this is a good way for the scrub master to kind of monitor the board and monitor the sprint in the progress of the sprint and, uh, basically following up with the team, having your daily stand up meetings, touching base on the status of the tickets and what each member of the teams working on and if there any blockers, so on and so forth. So that takes care of creating and running a sprint. Now let's go on to the next video where we'll set up some software versions 20. Creating software versions in Scrum: let's create some versions for the project. So if I go back to the backlog view and I have the versions panel already visible here, so what I can do is I can click on, create a version and type in the name, description, start and projected release date. Now, I can also do this by going to the releases page. So basically this page consists of all the version, so versions are your targeted software releases. Hence they call this page releases, which basically contains all the versions of your software so I can create versions by going to this page as well. So the first version I'm going to let's just call it version one team lead section and ah, the started its optional releasing. It's also optional, but we can pick one just ah, just for data sake. And you can provide a description and then you can add it. So it's created a version. And now let's create Version two, which is the men section, and, ah so we can project usually, since the release date is set to March 12th you may want to start the next version after that and then have a projected release date for a week later, or whatever your team or the product owner made the site. So you can add that now you've got two versions. So if you go back to the battle of you and you expand the versions panel, you'll see the versions on here. And what I'm going to do is I am going to take the current issues in the sprint and add them to the first version, which is what we're going to be releasing first. So now it automatically updated all those issues. Ah, and put in the label off all of them being part of version one. And, ah, it's also updated a progress bar for version one. So you can kind of see how far you have progressed with this version and obviously wants all the issues air complete. Right now, there are four completed, and you can even see the estimate. That's Ah, that that was the total estimate of the Sprint, and you can go into the details of the version. So let's go ahead and do that. So this has brought you to the specific version page, which you can also go to our go by accessing the releases page and, ah, so this is basically a summary of that version. It contains all the issues that are a part of. It tells you how many air complete harmony or in progress and how many are still in to do, and it's got the dates of the top. You can even set up release notes, which will take a look at and you've got a release button on the top, right? So once all the tickets in this version are complete, you can go ahead and actually release that version of the software. So when you click on release now, right now, it's noticing that there are four unresolved issues. So it's giving me options of either ignoring and proceeding with the release or moving the issues to another version, which you can definitely do. So I'm just gonna cancel this for now because we're not ready to release this just yet. But this is where you can kind of get an overview off your version and what different? What issues are contained in each of the versions that you're targeting to release. Now let's go to release notes and take a look here. This basically contains all the issues that are part of it, and you can go in and configure the release notes to generate the release notes and a format where you can copy and paste and use somewhere else. So, for example, I think right now it's creating it in an a c amel format. So if you had create it generates an HTML of basically list of all the issues that are part of this version, which you can just use Ah, in another document, if if you will. So that's the That's the release notes. So let's go ahead and actually move over to the sample scrum Board because they also have a couple of versions configured. So if we go to the releases page for this project, so right now they've got version one, which was already released. And once again, this is all sample data the Jura generated. So if we go into version one, you'll see that it was released on this particular date. All the issues were done so on and so forth. So this is how you can kind of create versions for your project as you're working on them and you can find out how you want to group features and how you want to release them, you can go ahead and create your versions and then add the respective tickets, which could be in the backlog and just add them to the version so they could be trucked accordingly. Now let's take a look and switch over to the Can van format and look at how we would be able to set up releases for a can ban project. 21. Creating software releases in Kanban: Let's take a look at how we would do releases for a can ban project. So I have here the sample can man Project board and this is the current state of the board . So it looks like we've got to bugs that are complete. We've got a bug in a story that is still in the to do or selected for development column. And, um, the backlog column isn't there because we set up a separate backlog of you four can ban board. However, looks like we've got two tasks over here or I guess, sub tasks, um, and a bug in progress. And both of them are in the expedite and fairly urgent swimming. So as a support team, for example, if a support teams working on this board and they're looking at this, they see that these are the most urgent tickets to work on. So let's just pretend that we did work on them and we're gonna move these tickets to the Don Kam. So I'm gonna move these urgent tickets to the done column and now we've got a set of tickets here, or issues that we are ready to release. So what we can do is we can just go up here to the top right and select release and select new version, and we can call this the Can Ban Release one and the release date of today. You can provide a description so worked on some urgent issues and you select release and then tells you that there are five issues that will be released and it all adds up. So let's go ahead and click release. So it did that and automatically updated the Sprint or sorry, the Can Van board to remove all those issues that were in the Don column. And this is where that sub filter comes into play by making sure that the issues that are released no longer appear here just to make it more manageable and view as you only want to look at, the tickets that are that still require work to be done. So now you can go to the releases page here for the Can ban project, and you will see that the Can Bend release appears over here as the latest release that was done now, Geral, when generating the sample data, also created a sample release, and that's over here but let's take a look and go into the can van release. So it looks just like the release in Ah, the scrum project. You've got five issues. Five issues were done and you've got your release date. You can once again generate release notes, and this is kind of a summary off what that release included, and going forward as your team as your support team would continue working on the can ban board and move issues from left to right and then generate releases grouping issues into releases. You can always come back here and you can always look at what, uh, what released contained what issues. So it's a good way to track and kind of organize your release pipeline for your can band related projects. 22. Creating an agile board with multiple projects: in this video, we're going to go through how you can create an agile board with multiple projects. Now, before I move forward with that, one thing that I haven't been doing is I haven't been keeping this sprint up to date. So we had talked about how we can set up versions. And we've also ah, walk through how you can create releases in Cambon. So what I can do is I can actually select these two sprints, are these two issues and move them to the done column. Now, what I'm gonna do here is before I close the sprint, I obviously want to make sure that I complete all the issues. So I'm just going to bring this issue up top to make it the next one that we're gonna work on, which is right now talking about agile aboard creation. So I have walked through how we can create projects, and usually what happens is because I'm creating a project of a screamer can ban format. It automatically creates the board for me. So we haven't really gone through how you would create a board from scratch. So let's go ahead and do that. So if I go to view all boards and I can click on Create Board over here, and what that's gonna give me is it's going to give me either an option off. Do I want a scrum board or do I want a can Bend board? So for the sake of an example, let's just go with the scrum board for now and again. I can create a board with sample data, but I'm just going to create a scrum board and you're gonna see these three options here. So I can either create a board from a completely new software project or I can create a board from an existing project. In fact, one or more projects or I can create a board from an existing saved filter. So remember how we mentioned that the filter is one of the main components of a board in terms of determining what issues show up on the board. So if you have a saved filter injera, you can create a board using that filter that pre created filter. So let's just see what happens If I select a new software project and hit next. It's going to ask for a project name of Project Key. So basically the same steps that we went through when we created a project. So I'm not gonna go through that right now. Just one. I just wanted to show you what that looks like. And if I go with the existing filter option, I just specified the board name and I can pick one of the existing filters and it would create the board for me using that further. What I'm gonna pick for now, though, is creating a board using an existing project. So I'm going to call this the Combined Scrum Board and I'm going to pick the two scrum projects that have created So one is my gender course, and the other is the sample scrum project. And I'm going to create the sport so it automatically takes me to the backlog of you. And you can see here that now it's displaying all the issues that are part of those two projects the jury course project as well as thes sample Sprint project. So, um and and given that we have to sprint's that are ongoing, we have a sprint as part of the sample project and we've got Argerich or Sprint going on so you can see both of them over here and you can see the backlog containing all the other tickets. And now if we take a look at the active Sprint board, given that right now there are two sprints. It's showing me all the issues for both the sprints. But I can go ahead and I can pick just the jerk or sprint, and it will show me just, ah, issues related to or within that sprint and same thing. If I go with the sample sprint to now, even though we you know, when we were looking at just the Gear course Sprint board, we had removed the in progress status. So hence the in progress column wasn't appearing. But given now that this agile board is a new board, it's going to configure it based on the default settings. So it's going to show all the columns again. But we can go and consider this board, and let's just take a look and see how it's configured. So we've got the name. We've got the filter. So when I created the board, it automatically created a filter, and the filter basically takes in all the issues a song as the project is either the sample scrum or the year, of course. And it is also shared with all users that are using either one of these projects. And you can see here that it's listing to projects part of this board. Let's take a look at the columns so conveniently. There are three columns because both of these projects use the exact same workflow now in the event that you are creating a scrum board. Ah, from multiple projects and each of those projects have different work flows with different statuses. Then what would usually happen is all those other statuses will appear here in the unmapped statuses column, and then you would be able to click and drag them into the respective columns. Or you can create additional columns and basically customized the board, depending on how you want to see them. And everything else is pretty much the same as what we had discussed before. You can go in and customize and configure this board based on how you want to visualize it . So now what is a realistic scenario or use case for doing something like this? Well, let's say you are the product owner or the project manager. But you are managing multiple projects and you've got one development team and they are working on two separate projects, each of which have their own sprint board. Now what you can do is instead of having to always go into the respective Sprint or the respective boards and monitoring them separately, you can create one agile board and incorporate all the issues for both those sprints. So you can kind of see what's going on overall, especially if it is one team. If it's the same team that's working on both projects, you can kind of see, um, you know how how the issues air, stocking up on the done column versus and progress versus to do so. That's kind of one of the realistic scenarios where something like this would come into play where you would be creating agile boards from scratch, with multiple projects being fed into them. 23. Closing sprints and viewing sprint reports: So in the last video, we walked through how you could create an agile board from scratch. And so we can now mark this item as done. It looks like we only have one more item in the section or Sprint. So let's look at how we would close a sprint. Now, Before I do that, I'm just gonna go back into the backlog view and I'm going to create another task. And this is just, for example, purposes. And I'm going to say this will be added in Sprint but not completed. So, for example, you know, in many scenarios you might be or the development team I'd be working in a sprint. And either they're able to finish their work early on, and they're able to add or bring additional items from the backlog into the sprint. Or there are some urgent items that come up that need to be, um, squeezed into the sprint, and that might result in some other items being taken out of the sprint. So I just wanted to show you what that looks like. So if I, for whatever reason, had to push this into the sprint, I can either drag it in or I can right click me, uh, kind of that too quickly. So I can either right click and send it to the sprint, or I can drag it into that sprint. Now, when I do drag it in, Jura warns me that by doing this I am essentially affecting the scope of the sprint. So obviously, um, gear understand that it's important to, you know, to respect the scope and what has been forecasted and estimated to be completed during a sprint that that doesn't get affected. So anything that you modify whether you add an item or take an item out, it will warn using that, you know the scope of the sprint is going to be affected. So if you agree with that, you can just had confirmed and jeer goes ahead and adds that into the sprint. Now let me make another change as well, just for just for testing purposes or example purposes. So for this issue that I still have open, I am going to update the estimate to 2.5 hours. Now you'll see that it doesn't affect the remaining estimate, so if you want to update that as well um, you can do the exact same thing so I can do to two hours and 30 minutes, so it should save that. And I'll tell you why I'm doing that in just a moment. So now I'm gonna go back to the sprint view, and I am going to Now let me try to complete this. Also, if I scroll down, you'll see that that issue was added here. And if you remember, when we created this board, we had configured the swim lanes to be based on Epix. So all these issues that are under this epic are showing up in this lean and because this task does not have an epic associated with it or it's not part of an epic, it's showing up in this swim lane under issues without epics. So what I'm gonna do, because I'm going to take this issue and market as done, and I'm going to leave this issue in the in the two new column and I'm going to try to complete the sprint. So it's going to tell me that eight issues were done and one issue was incomplete so I can go ahead and complete the sprint and What it will do is that it'll essentially just take all the incomplete issues and move it back to the backlog so you can use it and put it back into the next sprint when you're doing your next backlog grooming. So let's go ahead and complete this sprint and you'll see that it automatically takes me to the reports page and it gives me a report off the sprint. So at the top here it says it's it was closed by the administrator. These air, the dates associated with it. There's a quick burn down chart over here. Now, I know that this burn on chart is not chewing data and in the form that you would normally expect to see it just because the sprint was kind of done in a very unorthodox manner, obviously. So if you come down here, you see a list of all the completed issues as well as issues that were not completed. And one thing to note here is this particular item has an ass trick beside it, And that is because it lets you know that this issue was added to the sprint after the start time. So just kind of give you an overview of what happened in this meant, um it makes it known that you know, if there were tickets that affected the scope, it differentiates those tickets just so you can see what happened during that sprint. Similarly, you can see here that this particular issue the one that I just updated the time it shows you that the original time estimate was was changed. And now the new estimate ended up becoming this. And it kind of gives you the, uh, the total changes. Well, so the original estimate was two days, 15 minutes, and that became two days, two hours, 15 minutes. So as you're reviewing the sprint, this is kind of the report or the page that the team would look at during thes Sprint Review or the Sprint retrospective meeting. More so the review. Because that's when you're talking about what you were able to complete and what you couldn't complete. And, you know, if there were any things that came up that that made you not achieve the goal that you had initially set out, So that's a quick example of thes spring report. Now, keep in mind that gear also offers other reports that you can look at. I'm not going to go into all of them in detail right now. In fact, it really depends on what exactly you or your team might be looking for. So what I would suggest is to go, and you don't try some of these out and try to generate some of these reports and see what gets return. So, for example, if I go to the burnout chart, you'll see that it doesn't really give me the data in a way that you would expect to see it just cause I literally started and ended the sprint in the same day. But this great line, basically, is your guideline of how the work should proceed or progress through the Sprint, based on how many days are investment. And then as the development team goes in and logs work, it is able to populate that on a day by day basis, and you're able to see if you are pretty much on track. So if the amount of work done matches this line coming down than your on track, however, if the amount of work done ends up being less than where you're forecasted to be, then obviously the work that you, the work that's left to complete, that Sprint obviously keeps increasing. So this chart is a good indication of whether you're on track. But obviously your team has to follow certain guidelines to be updating things and updating tickets to make sure that this chart also gets updated. Ah, let's see what else they have here. So they have a velocity chart, so maybe we can look at that yet. So this basically populates how much effort or how many hours of work you were able to complete. And as you start and close sprints, it's going to populate your velocity for each of the sprint and kind of give you an idea and let your team determine what your team's velocity is in terms of how many hours of work the team can complete within a given sprint. And now one more final thing that we need to do before we can properly close off the section is remember that we had created a version to represent a section, so it looks like all the issues air done so we can go into that version now and we can release it So let's go ahead and do that. So I'll click on release, and it just populates today's date, which is the release date and you click on release. And there you go. Now that version has been released and going forward. It's there in your history, and any time you need to come back and look at all the versions in the past that have been released and all the issues that were part of that, you can come here and you can select that and view all the details for all the releases. So that brings us to the end of the team lead section. Now let's take a step. Ah, deeper into Ajira and look at how you can administer Jura and all the various things that you can customize from a administration standpoint. 24. JIRA Admin navigation: in this video. I just want to show you the administration pages and how you would go about navigating them . Ah, and the reason I want to do this is because initially, I did get a little confused as to how all the administrative pages were set up. Ah, So hopefully, by walking through that things should clear up for you in case you run into the same situation. So here I'm logged in as my administrator account and a Z. You can see here this cause is available because I am an administrator and this cog would be missing if I was logged in is just a regular user without the administration privileges . So when I click on the cog, I get a drop down and you can see here that there are two main sections You got the Jura administration section, and then you've got this site administration section, and basically what happens here is that each one of these links technically go to the same page with the different tab that's enabled. So let me to show you an example and let me click on the 1st 1 here applications. So this takes me to the administration page, and you can see that there are various tabs over here which basically represent each of thes menu items. So if I click on any one of these menu items, it will just take me to the same page. But to that respective top that you just clicked on, so you could, I guess, call this the Mange era administration page, where you would go in and you can switch between these tops to configure or administer different aspect of Jura. So let's just go through them at a very high level. Ah, the applications administration. TOB basically entails anything to do with obligation level settings. So whether it's defining who gets access to the application, you've got some gear software configuration settings over here. Software labs. Some of these things will talk about in one of the later lectures. Let's just move into the projects top. And this is obviously where you would be able to configure or administer individual projects so you could click on each one of these, and it would take you to that individual project Settings Page and a quick note over here. This is where you would also be able to configure your project categories, so you can add categories, whatever works for your organization. If you've got multiple categories for projects, and then you can go back to your projects and you can add each one of them to our respective category, depending on how the team has set them up. Ah, the issues tab over here is where you can configure anything related to an issue, whether it's an issue, type or screens eso If I want to create an issue, What's green? Am I going to see what feels show up on those screens? Ah, and even workflow. So this is where you would configure all the work flows that are used by projects and gear up. Um, and they have a couple other things which will also take a look at in future lectures. The add ons tab is where you would obviously be able to go in and search for add ons. And given that this is a cloud account that I'm demo ing with, the add ons that appear here will be compatible on cloud so you can see the gods end a support. They've got some, ah, test management add ons, so on and so forth so you can obviously feel Frito to browse through the at and see if there's anything that your team might benefit from using. And then you can obviously do a free trial to see if it actually works for you or not. The system tab is where you would go in and configure higher level system related configuration. So, for example, whether it's global permissions, um, or even if you want to adjust, the look and feel of the era may be modified. That default system dashboard. So there are various things over here. Ah, and we'll touch on Ah, a few of them. I guess the more important ones. Ah, in this section, of course. Now this is where something interesting happens. So I'm going to click on the next time, which is user management and watch what happens. All those tabs up top disappeared, and it's almost like I've reached a completely new website, so I no longer have the gear logo over here. Uh, this says site administration, there are no more tabs. So where did you take me? So turns out, let me just quick back. I didn't go back to this page that you're familiar with that we were working off of. So remember how I pointed out that there were two administrations accent sections. There are There's Jura administration and then site administration. So it turns out the way at last in sight it up is Jiro administration keeps you on this page where you can access every one of these. But the moment you go to any of the site administration pages, it takes you to a completely different site. Ah, that Ah, um, it's meant for specific configuration such as, you know, user management billing. And I guess the purpose of this was to give you the option to restrict access. So, for example, maybe there is a jeer a administrator but should not really have access to billing information. So I guess they segregated that to insure that the option was there to restrict access to the site administration if required. So I could click on any one of these over here as well, and it would take me back to the site administration page. And so when I do that, this is where you would be able to come in and configure users or groups, or look at your billing details so on and so forth. And if you want to go back to the previous administration pages more so related to Ji era, you could either come back on this cog and go to jeer administration. Or you can just click back to Jura and that will take you back to where you came from. And then again, you can switch between the jeer administration. And if I click on any one of these again, it will take me back to the site administration page. So I just wanted to walk through this because initially every time I came to this page, I would get a little confused because I'd wonder where did all the other administrative tabs go? And then I realized later on that this was done on purpose and, ah, they segregated it like this on purpose. So hopefully that should clear things up for you. And when you're getting into this for the first time now that you're familiar with it, you won't get lost. So since we are on the site administration, we're going to start now by creating a user and then building off that in talking about groups and then permission so on and so forth. So let's get right into creating a user in the next video 25. Creating a new user: in this video, we are going to create a user. So if I go back here to the administration, cog and let's go to user management. So that will take me to the site administration page and by default render the user's page . So here you can see that this year instance currently has to users. One is the administration account that I have been using, And, uh, I actually created a separate email address for this just so I can show you how to create a user. The email address amusing is your course at gmail dot com, and when I created this other user as I was walking through the section of working within an agile team, I could I used the email address Year course plus user at gmail dot com. And, ah, I don't know if you're familiar with this, but this is a cool feature about Gmail, and, I believe also works with Hotmail eyes that you can add a plus and then anything after the plus. And what happens is all of that basically gets ignored and would just send ah, that email to the whatever is proceeding that plus, So it would just go to jeer course at gmail dot com. However, it is still treated as a completely unique and different email address, so that's what I'll be doing. So in order to create a new user, it's actually very, very simple. So let's just create a John Smith user and I havent there already. So I'm just going to label it as user, just so we can identify it easily. And the email I'm going to use is your course plus J s for John Smith at gmail dot com. And I'll go ahead and click on Create Users. And what that's going to do is it's going to screen the user and send an email to that user . So I have Gmail open here. And so there you go. I got the email and you can also see here that I've been getting notifications. So as that KS user has been making changes to the various boards or various issues and updating issues, Ah, given that I'm logged in as theater administrator right now, the administrators Gmail account, I have been getting notifications of all those changes that KS user has been doing to my tickets. So let's just take a look at this email that we can that we got here. And ah, it's basically telling me that an account was created for me and that I should set my new password. So let me just go ahead and do that. Just use a random passer for now and said it and it Ah, well, I'm already logged in as the administrator. So technically, it's keeping that session alive, so I'm still logged in as the administrator. So what I'll do is I will just back out of this and log out, confirm, log out. Let's go back to the log in page and the user name that would have been created would have been just year course and Js and let me use the password. And so, the first time logging in his user, it's just gonna go through some logistics of setting up. I can choose an avatar. They've got some pre defined one. So this is Go with that guy and go next. And now what? Ah, I guess you're a gives me some options. So do I want to start by searching for issues or create an issue? Let's just explore the current projects so now and logged in as the John Smith user. And, ah, I'm able to view all the projects in here, So that's how you would do it. Let me go back to my administrate to account, though, just going to actually let me close this tab and go back to here. And if I do it, refresh and probably yet logged out. So let me log in over here. And so I'm back in the site administration page and you can see that John Smith user has been created. And, ah, you can see that the user also activated the profile as otherwise the the text over here would just be resend, which means that you can resend that confirmation email in case the user forgot to activate the account and set their password. You can always re send that email, so let's go into this user and take a look at what we can see. So as an administrator, I can see that this user has access to gear software and we'll talk about that in a little more detail in just a bit. But you can also see the last session of the user. The last log in and various things you can edit the user. You can change the user's password on behalf. So in case you know the user forgets their password, obviously they can reset it. But for some reason, if you need to override that, you can come in and you can change their password. You can also deactivate or delete the user now. One thing to keep in mind is that if this user has been fairly active in the Jura instance ah, and has gone and updated tickets or issues made comments had issues assigned to that user, then you wouldn't be able to just delete that user. And I believe Europe prevents you from doing that. But what you could do is you can deactivate them so that user remains injera. But you're essentially not paying, Ah, license for that user. But you would be able to continue using that user in terms of searches. So if you want to look at all issues that that user had worked on, you could still do that, which is beneficial because if you had a developer as part of a team or any team member that's been very active injera, you don't want all their activity to be wiped out in history. So hence jeer allows you to just deactivate that account. And ah, I guess lastly, what I'll mention over here is you can see that there is a group that this user is a part of. And this is something that Jura does in that they have a default group called dear software users. And so, for any cloud instance that you create and any user that you create on the cloud the default setting is that Jiro will add you to this group. And the reason being is that any user that's part of this group basically gets access to this Jura instance and they're able to log in. So ah, one thing that you may have noticed here is there is a log in button. So as an administrator, I could log in as the user, you know, in case I needed to do any trouble shooting and what not And that user would actually get any mail every time the administrator logs in, just letting them know that you know, the cloud Administrator has logged in using your account s, so just keep that in mind as well But let me just show you how this works. So if I click here, it's going to love me in his John Smith. And here I am and I can see John Smith's default dashboard. I can go in and view all projects. And while I'm browsing, Jiro lets me know that I'm temporarily logged in as John Smith. So when I'm done, I should switch back to my account. So let me just go back to my account. So it takes me back here. So that's a cool thing that you can do as an administrator. Now, coming back to that application, access and the group, you'll notice that if I uncheck this, I'm basically telling dear that this user no longer has access to this Jiro Software instance. And so you saw that in automatically God rid of that group. So now if I try to log in as the user, you'll see that I'm not logged in. I still have a log in button over there, which I can't really do anything with. It just doesn't let me do anything or see anything. So let me switch back and let me give this user access back to jeer software and you'll see that he got added back to the group and I would be able to log in. And let's just try that quickly and make sure that it worked. Yep, there you go. So I have access. I can see the system dashboard. I have access to my project so on and so forth. And so this would be a good segue. Wait to talking about groups and let's do that in the next video. 26. Creating groups and access controls: in this video, we're going to be setting up a group. So what is a group? A group is basically a collection of users. And so, for example, if you want to configure permissions on anything with injera for a group of people, rather than doing it individually for each person, it would obviously be better to create a group and add those users to the group and just configure the permissions for that group. So, obviously, that is one of the many advantages of having groups injera and some of the things that you can configure around groups are global permissions or even specific access to projects or even the overall access to the Jiro application. So let's do that. Let's create a group as an example, and let's see how we can give that group access to this year instance. So over here you'll see that I'm in the site administration page and I have group selected , and these are a bunch of groups that genera created by default. We have already briefly talked about the genius software uses group, so basically, this is the default group that pretty much any user that you create Angie era will be added into these site at Men Group Is Thebe primary? Ah, I guess not even Jura. It is Primary administration group, so this group basically has access to jeer administration as well as site administration. On the other hand, the Jura Administrator group and even the just General Administrative Group these two groups only have access to jeer a administration but not the site administration to remember how we were talking about the purpose of segregating Bolger administration inside administration is so that you have the ability of assigning a user the ability to administer various other Jiro related items, such as issues, work flows, project level, things like that, but not have access to things like user management in creation or even billing related information. So that's where the difference between the site and men and then the administrator, general administrator groups, come in Now I'm not entirely sure to be honest as to why there is a jeer, a administrators group and an administrator's group, because it looks like these two are essentially the same thing. However, this was created for me by default, and so I'm not really going to play around with it. But a Sui take a deeper look in Ajira, you'll notice that this does appear a bit redundant. Ah, but for the time being we're gonna leave things as is. So let's go ahead now. Ah, since we've taken a look at the default groups and let's now create our own custom group. So the example that I'm going to assume is that we have a group of external consultants and we need to give them access to Ajira. But because they are external consultants, we don't want them to be just like any other team member. That's within the organization. So the first thing that we would do is create a separate group for them, and then we can start talking about how we configure their permissions to give them access toe, only the things that they need to see. Unlike any other team member, that's within the organization. So let's do that. I'm going to go over here and click create group, and it's very simple. So let me just call this external consultants, and I don't need to put in a description, but you can obviously, right now there are no members in the group, so let's go into users now, and I'm going to create a new user. Ah, and let's just call this user Richard Hendricks as an example, and I'm going to put consultant just so it's easy for us to remember and visualize. And for this one, I'm going to just use the jeer course plus R H at gmail dot com. So I will end up getting an email. But I'll leave that for now, and I won't go ahead and activated. But now you can see that there is a Richard Hendricks consultant created in our gear Instance. So if I go into that users details as predicted, Ah, that user would have been added to the jeer software users. So basically, now that user, that consultant has access to Ajira and pretty much everything that any other user would see S O. What we would need to do is let's go back to the groups page and let's go into external consultants. And let's add Richard into this group, so I'm going to click, add and let's look for the name. And there he is gonna select user. So now Richard is part of the consultants group. But did that do anything different. So if I go back to users and if I go into the user's page, he's still part of the Gear Software Users group. So what I would need to do is I would then need to remove this group. But what does that do? It automatically revokes Richards access to Jura because we haven't given access to the external consultants group to jeer A. So we'll need to do that. And we can confirm this theory by trying to log in as Richard and let's see what happens. Yeah, it's not really logging in its not able to. Our Richard is not able to see anything here. So let's go back to my administrator account and let me now assign access to this group So that is done by going into application access over here. So let's walk through this. This basically tells me that these are the users that have access to jeer software. Keep in mind as well that if you have other applications installed, so just confluence or anything else. Ah, I believe it would appear as a separate tab and you would be able to see all the users that that have access to that particular application. Now you congrats access. By clicking over here, you can view the user default. So if we look at user defaults, it basically tells me here that any new user that we create is basically given access to Jura software. Ah, and I think we should probably leave things as is, because that's likely what's going to happen. That's the only reason you would create users. Injera is to give them access to it, so let's keep that as the default. If you want to grant access to Richard specifically, you can obviously come here. You can select the obligations in this case. We only have Jiro software, so you can select that when you can type. Richard's name shows up over here and you can grant him access. But obviously that's not what we're trying to do here. We want to give access to the group in case we have other external consultants as well. All we would need to do is just add them to this group and automatically all the permissions we've configured for that group will automatically get assigned to that user to any new user that we create and add to that group. So what will need to do is we'll need to go into view configuration over here. So this is the obligation access configuration page. And here you can see that the groups that get access to jeer software are listed here, and the groups that are listed under your administration or listed here and the default here implies that any user is granted access, or any user that's part of this group is granted access by default to jeer software. So what we need to do is we need to go in here and add the consultants group to Jura software. So we're basically accessing Grant O. R. Granting access to their software. We don't want to make it a default group because essentially then every new user will get added to this so we'll keep that unchecked grant access. So now external consultants has access to jurors software. So if we go back to users and we go into Richard Hendricks, who is part of that consultants group and try to log in as the user, you'll see that now we're seeing the dashboard. We're seeing projects issues, so we now have access as a consultant and the advantage here is that they are part of a different group. They're not part of the standard gear, a software users group which all your other team members would be part of. And now you can start going in and configuring individual settings and permissions for this consultants group. So let's now start getting into permissions and talk about all the different levels of permissions starting in the next video. 27. Understanding the different permission levels: Now we're getting into Jiro permissions and talking about the different levels of permissions that you can configure. We created some users. We created a group, and we walked through how we can add users to groups. Now it's up to us to go ahead and configure the correct permissions for the different groups, and basically Geo breaks down the permissions into two main levels. You've got the global permissions, which applied to the overall application, and we'll take a look at some of the some examples of global permissions that you can set. And then there are project specific permissions, which apply only to each project. Um, so whether it is, you're able to access the project or who can create and edit or delete issues or comment on certain issues or upload attachments pretty much anything to do with items or issues. Within that project, the permissions are broken down in a to a pretty granular level, and each of those permissions can be defined for each given project. So let's first start by taking a quick look at examples of global permissions. So over here I am back on the administration page and I have selected the system tab, and you can go to the global permissions to take a look at what comprises of global permission. So things like being able to browse users. So, for example, when you are creating an issue and you want to assign that usually that issue to someone when you click on the assigning field and start typing a name and it's suggesting, Ah, whole bunch of users to you available users. So that is kind of, ah, permission or a feature that's global to jeer. A. So either you're able to view and browse the other users. Or you can't similarly creating shared objects, whether it's dashboards or filters. So as a user Ah, I can go ahead and I can. I can do a search and Aiken save the filter for future use. Now, I also have the ability to share that filter with other users, but only if I have this particular global permission. Ah, and then we'll take a look at some of the other ones in another video. But I just wanted to give you Ah, quick look at a high level at some of these examples, some of these global permissions that you can configure that are based on an application level now coming back to project permissions. How can Oh, sorry. Before I continue to product permission, just wanted to show that Ah, we were talking about assigning groups to these permission. So this is where you would do that. And you can see that for each and every one of these permissions global permissions, they've basically got all the groups of signs so cited man's administrators and the jeers software users. So pretty much any user that you create by default gets added to the Geo software users and would hence, by default, get all these global permissions. Now, if you remember the new group that we created, which was for the external consultants, they haven't been added into any of thes global permissions, so they would actually not be able to go ahead and do any of the stuff. And we'll actually show you, uh, the details of all of that in the next video. So now let's come back to project permissions. How would you be able to add groups to project permissions or a sign project permissions to groups? So this is pretty much broken into project permission schemes So a group is given all the actions or permissions to perform actions for a project through a permission scheme. So and I'll show you an example, and it will see more clear once I show it to you. But just to give you the theory first. So once again a project has a bunch of actions that you can perform on it, whether it's like creating a issue or editing or deleting issues, being able to browse the project and all these are defined in a permission scheme and that permission scheme. Then get assigned to a project so you can go in and you can configure a permission scheme in a way that you can specify that you know, this group has access or is able to browse a project. This project, um, and you know so and so Group is able to view and edit issues, and you can lay out that permissions came accordingly, and then you can assign that entire permission scheme to a project. In fact, you can assign it to multiple projects, but each project can only have one permission scheme. So now let's take a look at that. I'm going to go into the projects. Top over here and let's pick the Jeer Accords project. So when I click on that, it takes me to the Project Settings Page and you'll notice that I'm back in that project navigation. I can go to my backlog active Sprint releases. And because I'm an administrator, I also have access to the project settings. So what I'm gonna do is I'm gonna skip all of this for now. We'll cover all of this and other videos, but let's just take a look at permissions. So when I click on permissions, you'll see that this project is using the default software scheme. Or, I should say, the Default Software Scheme permission scheme. And over here you've got a whole bunch of those actions laid out. So administering projects, browsing the projects, managing sprints. And then you've got issued related permission, such as being able to assign users cloning, creating, deleting, editing various things like that. You got permissions around voting and watching issues on commenting attachments, time tracking so on and so forth and you can get pretty get granular. With all of these, you can assign specific users or groups to each and every one of these actions. So all these actions are defined accordingly in a scheme called permission scheme that has been assigned to this project. So where can you find all the permission schemes? Injera. So for that we would have to go back to the administration section and go to issues and then at the bottom. Over here you have permission schemes so you can take a look. And you see that the default software scheme is what Jiro has created. This is the default scheme that gear applies to all software based projects. And so all the projects we've created, whether it's can ban or the sample scrum project or even the Jiro course project, all of them are using this scheme. Now I can go in and I can create new permission schemes. And then I can customize what people can do for each of those actions. And then I can assign that new scheme to any one of these projects. So that's at a high level, how it works going back to over here. So just to summarize, you've got to permissions. Once again, the global permissions apply to the overall application, something that you can do across Jura, whereas the project permissions could get pretty granular and define what users or groups conduce you within a given project. And all of that is defined through what they call a permission skip. Now let's take a quick moment and, ah, in the next video, we're going to just go into the global permissions in a little more detail just so you can understand what each of them represent. 28. Global permissions explained: Let's take a look at some of the global permissions that have been defined by Jere, so we'll start off from the top. Actually, that will skip the 1st 1 Gear administrators is fairly self explanatory. You can see that it's already added the ah, the basic administration groups to that. Ah, and it's ah, this this permission global permission gives you the ability to perform the main administrative functions. And, ah, if you remember in one of the previous lectures I was talking about the difference between Jura administrators and the administrators group, and I said that it did seem that they were fairly redundant. And the reason being is because you can see that those two groups have been added to pretty much all of the global permissions. But I think the purpose for gear creating them is maybe to give you an indication that you can segregate the different administrative functions Ah, or any of these global permission. So if you want some users to have only a specific set of Ghira administrative functions, you could you could create two different administrative groups, and perhaps that is where this could be useful. So skipping that, let's just talk about the remaining global permissions that we have here. So looking at the 1st 1 the browse users, I think in the last video I mentioned that this was referring to the ability to find names when you're trying to assign an issue to someone. So so you try to create an issue and you want to assign assigned the issue to someone using the assigning feel field. And when you, when you select or highlight that field, it would give you a list of users kind of suggesting the users that are available, that you can assign that issue, too. So that was my mistake. That's not what this is referring to, because since that is around an issue, those permissions would be controlled by the specific project permissions. However, this is a global permission, and what this is actually referring to is, for example, if you're trying to do a search and you want to search by a sign E, that's where it wouldn't display all the issues available. Injera because you don't have a global permission because searching is kind of a global functionality. And so, in order to be able to see all the users and be able to select from a suggestion list. Ah, filtering by assigning than you would need this global permission, and I'll demonstrate that to you in just a bit. The creating shared object school permission basically refers to being able to create dashboards and filters and be able to share them with other users. Injera um, the managing group of their subscriptions. That's more so around creating a subscription from a filter, which will I'll show you in a second as well. And bulk change basically allows you to change or modify ah group of issues at the same time. So let's take a look at these one by one. I am currently logged in as an administrator. So what I'm going to do first is I'm going to go into issues and I'm going to go into manage filters so you can see here there some of these filters. And if I click on this one, for example, so this is the ah, the filter that was created when I created that that example agile board and, ah so you can see that when I select a sign e. I can filter by all these suggested users or I can start typing a user, and it'll suggest me names that match what I'm typing. So that's there. If I click on details for this filter Ah, you can see that right now this filter is already visible to people with these projects, and I can edit the permissions and Aiken shared with more people either groups or individual users. And the last thing here is if I click on details again and I click on subscriptions if I want to create a subscription for it, what this does is basically ah, it's a feature that allows jeered ascend results of a filter either on a daily basis or at a time interval that you can configure and ah, notice that I can either have it send it to myself. Or I can also set it up for different groups within JIA so I can see a list of groups available over here. So I'm just gonna cancel that. And the last thing I want to show you as an administrator is eso Right now, this filter is returning a bunch of issues and I can go in here and Aiken bulk change all 38 issues which will take a look at in another video. But, ah, it's basically an option for me, too. Edit something about all these issues at the same time. So what I'm going to do now is I'm going to go back into user management. And if you remember, for each of those global permissions, the external consultants group was not added to any of the global permission. So, technically, all the users. So, for example, Richard Hendricks should not have any of those global permissions. So what I'm going to do is I'm going to actually log in as this user and let's take a look at the exact same thing. So I'm going to go to issues and what's going to manage filters? No, it will be interesting yet. Okay, so this filter is available because this user does have access to all the projects, at least for now. And so they're able to see this filter. So let me click on this, and the first thing I showed you was being able to filter by assigning, but here you can see that it's not letting me or it's not suggesting any users to me. And if I type a name it doesn't really return any results. So that's one thing. Now if I go to details, that edit permission ability is isn't is gone. So hence I can't really share this filter with anyone. And if I wanted to create a new subscription, I don't have any option to specify whether it's for myself or for a group. The only option I have is just for myself. So hence you know I can't manage bulk filters, bulk filters subscription. We're sorry. I should say group filter subscriptions. I'm not able to configure ah, subscription and have it sent to a group. And the last thing that I'll do here as general warns me that I'm logged in is this user is I can't bulk edit issues either. So these were some of the examples eso let me actually click on something and hope that your uh no. I think I have to go to another page and yeah, than the pop up appears. So let me switch back to my account and I'm going to go back to jeer administration system global permissions. So just to summarize, we weren't able to find any assigning is when trying to filter for issues. We weren't able to share any filters, and you can do the same thing with dashboards or you will find the same restriction with dashboards. In this case, we just looked at filters and we were not able to set up or manage a group for their subscription. We could only do it for the logged in user. And finally we weren't able to make bulk changes to issues, So that's a summary and explanation of all the global permissions that exists within jeer. 29. Understanding Project Roles - Theory: Okay, We've taken a look at users groups and permission levels, and we identified the two permission levels as global permissions. And we saw some examples of the global permissions that year has. And we've also taken a look at how project permissions are assigned, and basically they're assigned through a permission scheme, which defines all the different actions that can be taken or performed on the project. And you're able to give each of those permissions to individual users or groups within that permission scheme, and then you can assign that permission scheme to a project. Now let's take a look at an example over here. So let's say you have user A Who has the ability or should be given the ability to create issues in Project A Onley and user be should be able to create issues in project Be on Lee . How would you go about setting this up, injera Well, so first thing is that you would need to create two permission schemes. And so, for example, in the first permission scheme for the create issue action, you would assign user A to that action and four permissions came to you would assign user be to the create issue action and then you would assign permission Scheme one to project A and then permissions came to to project be so because you have two different users that are supposed tohave the exact same responsibility in two different projects, you have to create two different permission schemes would if you have 1/3 project and either user A or user be can create an issue in that third project. Well, then you aren't able to use any of these existing permission schemes because each of these Onley allows one of the users. So if you want tohave another project where both these users can create issues, then you obviously have to create 1/3 permission scheme and you can assign both user A and user be to the create issue action and then that permission scheme you would assigned to the third project so you can see how unmanageable this can become if you have a lot of users within your team. And if you want to delegate responsibility for various actions, um, and if you want to get just even a little more granular, this starts to become pretty unmanageable. So Jura introduced something called project rules, and that pretty much solves the issue. And the way that works is you can define project rules across jeer. So it's kind of at the level of global permissions in the sense that it applies to all of the era so you can go in and you can configure project roles. And every single project that you create will have access to these rules. They will basically end up having all these roles within every single product that you create, and then you can take users and assign them to the project rules. And instead of assigning the users to the permission actions, you would assigned the project rules to the permission actions. And I know that this probably sounded a bit confusing, so I'm gonna try to lay it out and walk through it step by step. So first, let me explain again what I just talked about. A project rule is defined injera, and so you could take this this project role as an example. Once it's defined, Project A, as well as Project B will have this project rule. Now you can assign users or groups to the project role, and what happens is that this project role then gets added to permission schemes. So instead of adding users or groups straight into permission schemes, you first add them to the project rule for each of these projects. And then the project rule is added to the permission scheme. And then, of course, the permission scheme gets assigned back to the project. So this is how the flow would work. Now, maybe, let's use the example and try to understand this a little more. So going back to this example of user A only being able to create an issue in project and User be only being able to create a project or sorry issue in project be How would we solve that would project rules? Well, what would happen is we would create a project rule called issue Creator injure the moment you create that project rule injera. Both Project A and Project B will now have that project role. And what we'll do is for the create issue action. We're going to create only one permission scheme. We don't need to. We're only going to create one permission scheme and for the create issue action, we're going to assign the issue. Creator project rule to that action and then obviously will assign that same permission back to both projects. But what is the difference? The difference is that for Project Day we're only going to give users a that project rule that issue, create a product rule and for project be were only going to give you Zerby that project role. So basically, user A will have the issue creative project rule which has the create issue permission and that is assigned to project A. So hence user A gets to create issues and project a similarly user be Has the issue created project role in B which is assigned to the create issue permission which in turn comes back to project be and so hence user be can create issues and project be And that's kind of how it works. So going back to this example that we ended with one of the lectures previously, the only difference here, really is that in between groups and permission scheme, you add a project rule which is described here. So you're gonna add groups or even users to the project roll. The project role gets assigned to the permission schemes, the permission schemes get assigned to the projects, and every single project, in turn, has their own project rule. So let's actually go through this in Meiji era instance so that you can see it as an example, and we're going to do this in the next video. 30. Understanding Project Roles - Example: In the last video, we introduced the idea of project rules, and in this video we're going to actually walk through an example of what it means. So I mentioned that every single project has all the project rules that are defined injera , and you would then assigned the project rules to the permission scheme, and you would add users or groups to the project role. So let's take a look at what that means. So first of all, let's look at the project roles as their defined angina. So I am once again in the administration page, and I have the system top open and right above global permissions. You will see project roles. So if you click on that, this is where all the project rules across. Jura is configured or set up, and pretty much any project role that you create over here will be or can be used in any project that you create going forward. So right now, by default, Jura has to project rules, administrators and developers so and ah to define project rules again. It's basically a way of flexible way for you to associate users or groups with projects in various functions within a project. So the administrator and developer project rule are another way off, associating users and groups to the project. So that means there are users and groups within this project role. So let's take a look and see what the default members are. If we take a look at the administrators, we'll see that there's no default user. But we do have a default group, and so it's any user within the default group. So any user within the Jura administrator group So which makes sense, because this is the administrators project rule. And so you would want to add all the administrators to this role. We also have a developers rule. So let's see who's in the developers roll. There's no user, and there's no group so pretty much nobody in this ah project role. And I guess jeer A. Even though they created this project rule, they left it up to you to actually go in and configure it. So I'm gonna leave this for now because we'll be using this in another video. But what I'm gonna do is let's just use an example the same example that we defined a couple of slides up above here. Ah, which was yet this one. So we want user aid to be able to create issues and project a user be to be able to create issues and project. Be so what I'm gonna do is I'm going to create a project rule, and I'm going to call it the issue. Creator, I don't need to put a description, so I'm gonna add the project role. And now that I've created that project rule this issue creator rule is available in every single project and you'll see what I mean by that. And I'm not going to add any members to this because, uh, my goal is this project role is going to have the ability to create issues. I'm calling it the issue Creator project role and for for two different projects. I want to different people toe have that rule. So I'm not going to add anything here because if I add any user or group here, they become the default user or group toe have that role for all the projects. So I don't want that. So for now, I've only created the project role. Now I'm going to go into the individual projects So the two projects that I'm going to use our Jiro course and sample scrum project. So let me go. Ah, I'm just gonna open them up in you tabs here, So I'm gonna go to the gear course project first and in the Project Settings Page, you can see users and rules. So if I click on that, this is where it lists all the users that have the respective project rules. And so you can see that the administrator project rule is defined. There's no developer roll and there's no ah issue creator all that we just created just yet . That's because there's no user defined for that. So if I click on the rules drop down here, you can see OK, administrators have the jury administrators because that's what it was set as default developers have no one and the issue creator has no one. So what I'm gonna do is I'm gonna add one of our users to this project role. So let me add, I believe I have a John Smith user, so I'll add this guy to the issue Creator role. There we go. So we've added him to that role. Now I'm gonna go to the scrum sample project. I'm also gonna go with users and rules. And so over here, I think I may have been playing around, so I added, Ah, the administrator into the developers project role. Um, but I don't think that's going to bother us right now, so I'll just leave that as is and for So let me just take a look at the issue. Creator. Yep. No one is there. So I'm going to add a different user to this project. Will eso let me. How many know I don't want? Uh, what are the other users that I created? Yeah, so I had this ks user. So I'm going to use this guy for, uh, for being the issue creator in this project. So there you go. Now I've configured this. Now what else do I need to do? I need to let me actually refer to the diagram. So I have created a project rule called the Issue Creator for Project A of Assigned User A for project B of a sign user, be to the project rule. Now, what do I need to do? I need to take this project rule and I need to assign it and give the create issue action that project rule within the scheme. So let's go and do that. So that means I can close these tabs and I can go back to my administration page and, ah, the permission scheme is under issues. So if I go to issues and I go to permission schemes so all the three projects use this default software scheme. So if I go into there So now I'm in the permission scheme and I need to look for the create issue action. So that is under issue Permissions right there create issues. So right now it is granted to any logged in user. In fact, if you take a look at all of them pretty much, all the actions over here allow any user logged in to be able to do it. So I mean, I guess by Jeff by default jeras defaults software scheme. Uh, there's not a lot of security around it, so I think they leave it up to you to go in and configure and put a little more security and restrictions around them. So that's what I'm gonna do here as an example, but just for the create issues. Action. So what I'm gonna do is I'm gonna edit this and I'm going to grant the create issues permission to the project. Rule of issue, Creator. And I am going to remove this guy because I don't want any logged in user to be able to create issues something terrible. That And there you go. That's it. So let's go back to this flow chart years. So I have taken the create issue action. I have assigned the issue creator project rule to that action. I already know that this permission scheme is assigned to both projects. And I went in earlier to each of the projects and I assigned a different user to that project role. So technically, it should all be done. Now, when I log in as the first user, I am only able to create issues in the first project. When I log in is a second user, I should only be able to create issues in the second project. So let's see if that worked and just to refresh my memory, I'm going to go back into gear course just to make sure I'm aware of which user I put in for this guy. Okay, so John Smith can create issues in Gear course. So let's go back to the user management, and I'm going to log in as John Smith. And the expectation here is that I should be able to create an issue for Gear course, but I should not be able to create it for the sample scrum project. So if I click on this drop down, I seen no more matches. So ends. I can't create an issue for any other project, which is exactly what we wanted. Now, if we go back and we log in as that other user, So let me go to users again. And it's this ks user, and if I log in as this guy, it should be the opposite. So I should not be able to create a ticket or issue for jeer course. But I should be able to for these samples from Project. And there you go sample scrums available, and there's nothing else available. So there you go. That is an example and live demo off how you can take advantage of project rules. Um, another thing that I should actually mention is previously before I introduce project rules . I mentioned that you could add groups to permission schemes. That's something that you can still do. But obviously, given the example, I provided where if you want to get a little more granular and you've got multiple users that need to do the same function in different projects than by creating groups, it becomes unmanageable. So hence you can use project rules to bring about that functionality. The other advantage of project rolls over groups is that Onley Jiro administrators can add users to groups, whereas for project rules, the project administrator is able to do that because the project roles are already defined . It's just a matter of who gets what project role. So the project administrator is able to add and specify that so and so user can be a developer in this project because the developer project role has been defined. Or you can define a quality assurance project rule that has Theobald iti to close issues, and no one else has that ability. So then, for every project you can define which user or which group gets toe, have the Q A project rule and you don't need to contact your Jiro administrator to do that because it's on a project rule level and not the or the higher Jiro groups level. So hopefully that made sense. I think we've covered a lot of ground in terms of users, groups, permissions and how you assign permissions to users, groups and project rules, obviously, so now we're going to walk through an actual example of how all these come together. 31. Roles and Permissions Example - Part 1: we've talked about users, groups, project roles and permission schemes. Now let's go through an example. That kind of brings them all together. I try to think of an example that would somewhat mimic a real world scenario, so you may find yourself needing to set up similar kinds of permissions for your own team of the new organization. But if not, hopefully the example will go through enough scenarios to give you a better idea of thes features and how you can use them and hopefully should allow you to set up the permissions for your own team based on your own specific and unique requirements. So the objective is to create a new project with sample data. We will also create a consultant user that should only have access to this project alone but has the ability to work on issues within that project. We will also create a customer user who will also only have access to that project alone, but in this case will have read only access, So it's similar to the consultant. Ah, the consultant will be able to work on issues, but the customer has read only access, and both of which only have access to that. One project that we create will also create a project owner user that can administer the project and is also the one who can manage sprints. And, of course, we'll have a developer user that can work on issues. So what are the steps? If I wanted to go about creating something like this, what are the steps that I think would be best to follow? So first I'd obviously create the users and corresponding groups that I might end up using . Then I would create the product roles based on those users and groups, And then I would create a new permission scheme, uh, for the project and set the permissions based on the project roles that I just created. Once that's done, I can actually go ahead and create the new project. Now, why am I creating the project after have done the 1st 3 steps? The reason being is that if I decide to add any default members to the project rules that I create than any new project I create, going forward will automatically get those default members assigned to the project rules for that respective project. So that's why I decided to do it in that order. Now, want the project has created, I'll need to update the project to use the new permission scheme that I just created. And then, lastly, I would assign the right people to the project rules for that project, and that should be it. And then we'll log in as the individual users, and we'll take a look and see if everything ended up fitting together. So let's start off with creating the users and the corresponding groups, and I'll keep that note pad open on the side just so we can refer to it. So what I did was for the users that have created so far. We already had a consultant in the former Richard Hendricks. What I did was I converted John Smith and Ks two respective product or project owner and developer before I think I had users in the brackets. So I changed and and assigning John Smith to be the project owner and chaos to be the developer. Now who else do I need? So I've got consultant. I don't have the customer. I have the project owner and developer, so I need to create a customer. So let's go ahead, spin, create a customer, injure. And as we have walked through before, I'm just going to call this guy Erlich Bachman. And if you're wondering where I've come up with these names, including Richard Hendricks, their characters from a show called Silicon Valley, which I'm not sure if you've seen. But I really enjoy that show. And right now I'm completely digressing. So coming back to this, let's call this guy gear course at EBI vaginal dot com, and we'll create the user. Now if we take a look at the user, we see that he's part of gear soccer users Now, given that, actually, what I'm gonna do is I'm going to make it easier for us to recognize him. So I'm going to just add customer here. Save So now. Given that he's a customer, he technically shouldn't have access to Jura the way that all the internal users have access. So what I'm gonna do is I'm going to remove this group from Ehrlich, and now let's go ahead and create some groups so you can see that I like no longer has access to your software. So let's go into groups and these are the groups that we have so far. Ah, in fact, I created a new group called Year Developers, and I decided to assign the KS developer to that group. Reason being is, chances are you're going to have more than one developer in your team. And so, if you would ever need to assign developers to a particular project, it's good to have a group there by default that has all the developers. So for now, we just have one user to work with. But obviously you can add all your developers to this group. So I decided to create that. Now I'm going to create a group for the customers. So we already have one for external consultants. And let's just confirm your Richard as part of that, So that's great. So I'm going to create a group for the customers, and I am going to call this external customers create, and I will add Perlich to this group. All right, Excellent. Um, now, remember that when we were looking at er licks profile, we did not give him access. And now that we've created a new group, we can go into application access and we can go into the U configuration, and we see that external consultants yourself for user cited bins, all of access did your software. That's all we need to do is come in here and look for customers in grant access. So now if we go into, uh, no, not that one. We go back into the customers profile for a group and look at Ehrlich. You should now have access to jeer. There you go. Okay, so we've created groups that I believe we would need. Now let's go ahead and the next step would be to create the project roles. So that requires us to go back to your administration and the project. Roles are under system, so we'll click. Click on project roles. All right, So we saw in the last ah, few videos that the administrators and developers project rules were created by Jerry by default. And we saw that administrators had the default group of gear administrators, which makes sense. Now I believe developers had no one. So now that we've created a group for the developers, we can actually go ahead and add them in. So let's go ahead and do that had okay, so that should be good. Now what I'm going to do is I'm going to create a couple of new project rules. So let's create a project rule called Consultant. Now the man you can add in description if you want, But I'm just going to skip that for now. Customer and, ah, what other project rules can we think of? We want a product owner or project owner, uh, who was able to manage Sprint. So I think it would make sense to create a project owner s. So let's just call it Project Owner Project Rule. And I think that that should suffice for now. So what is the next up? Let's go ahead and create a new permission scheme for the project. So permission schemes, if you remember, are under issues. And also we never added any default members to those consultant, customer and project owner project roles because, ah, if you add any default members or groups than any new project you create, will automatically have those groups or members assigned to that project role and going, you know, in the real world scenario for each of these projects, you might have different project owners or consultants and customers, so it's better to leave that to the project specific setting and not set that as a JURA wide setting. So let's go into permission schemes over here. Now we can see that these three courses here are using the default software scheme. And if you remember, I'll just open the permissions up in a new tab. There wasn't much security around this permission scheme because pretty much everything, most of them most of the permissions have been given to any user that's logged in. Doesn't matter what group you're in. If you're able to log in Nigeria, you basically have access to ah lot of these things, including managing Spence. So we obviously do not want to use this scheme. Ah, and what I was thinking is that maybe we could have just copied it and it would have been easy for us to configure our own scheme. But in order to do that, if we ended up doing that, we would have to remove this setting the any logged in user from each and every one of them and add in what we want. So I think it will be easier. Let me actually just close this and go back to this tab, it will be easier for us to create a completely new scheme. So let me go ahead and do that. And I'll call this the main software scheme, assuming that, you know, perhaps this is the scheme permission scheme that I'll use going forward for all my software projects. So now that I have created the new scheme, I need to now go in and configure all the individual permissions. And this could end up being a fairly tedious task because there are a lot of permissions here and you basically have to go in one by one and assign the current project rule to each of these permissions. So we'll start from the top and we'll see how we go administer projects. So obviously this one I want to give ah, the ability to administer products to administrators. And, ah, as we had talked about, the project owner can administer the product. So let's give this permission to the project owner as well. Now, browsing projects who gets to browse projects pretty much every one of these guys. So the developer, as well as project owner, customer consultant, all of them are able to browse so browse means being able to actually see the project and issues within them. So now what does this require me to do? It looks like I'll have to go in and give this permission to each and every one of these guys. And if we want to do that for any one of these other permissions as well, we need to go in and click edit five times to assign that permission to all the five project rules. So what I think makes sense is for us actually create a new project rule. So I'm going to open up system in another tab and go back to the project rules on. I'm going to create a new project rule called Project Team. And the purpose of this is this project will basically represent all the team members. And so let's go back now and see how we can configure this. So now that have created the project roll, it should be available. And I am going to say that the browse projects can be given to the entire project team and then once we're configuring, the project will add everybody to this Project team project role, and we'll see that in just a bit, managing sprints. So we know that only one person can do that, and that is going to be the project owner viewing development tools. So this allows softer project to view the development related information such as commits reviews, build information. So I think this would apply to just the developers and perhaps the consultants as well, because they're going to be the ones working on the issues now. You could also add the project owner. I think we'll just leave it to these guys. For now, View read only workflow. There's no harm in seeing the workflow in read only format. So I think the project team and anyone in the project can look at that assign herbal users so users with this permission may be assigned to the issues. So again, I think allowing the entire team to do that is fine. Being able to assign issues to other people once again, I think having or allowing the entire team to do that as great so you can kind of notice a trend where a lot of these functions can be done by pretty much anyone in the project team . Then, as you go and create individual projects. It's up to you. Ah, and who you want to assign into that project team role. So whoever you assigned to the project team role will be able to do all these functions. So I'm just going to continue down this and I'm going to update all the permissions. Ah, positive video. Eso Just so you don't have to go through and spend time looking at me doing each and every one of these, and I'll recently video once I'm done and we can go through them quickly. 32. Roles and Permissions Example - Part 2: Alright, So I've gone down and I have configured all these permissions it ah didn't take me too long . And the advantage of doing this is, um or I guess the purpose of doing this and spending the time to configure each and every one of these notifications, of course, is that you would only need to really do it once and then going forward. The intention is that this software scheme can be used for any software project going forward. All you would need to do is for each specific project you configure who is part of each and every one of these projects rules. So I have assigned most of these permissions to the project team, cause obviously, you know, things like closing issues, creating issues, editing issues it makes sense for the whole team to be able to do that. But things like deleting issues or modifying the reporter or moving issues, you want to maybe keep that to just the project owner. Ah, so that's ah, what I've done for all all the permissions here. So things like manage watchers the ability to manage a watcher or set yourself or view who is watching an issue I don't see any harm in letting the project team do that. Um, similar to add comments, however, deleting all comments and editing all comments. Yeah, that something may be the only the project owner should be able to do, but editing or deleting your own comments? Yeah, anyone could do that. So anyone in the project and so on and so forth, I kept it that way to pretty much allow the project team to do most of these standard functions. So that takes care of the permission scheme. So now what would be the next step? And I noticed that I have five year twice a. Let me just update that. So after we've created the need permission, we can go ahead and create the new project. So let's go ahead and do that so I can go to projects create project, and we want to create sample data and let me pick a scrum project. You could pick anything, and I'll call this the permission Example project. I'm OK with the key that you're suggesting that's okay. You could technically make the project owner your project lead as well, but we'll leave that, as is to the administrator and let me submit that. And hopefully it won't take too long for dear to generate the sample data and create the project. All right. Looks like it is almost done. And I think it's going to take me straight to the agile board. And yet there it is. So now we can go into the project administration when we see that the project is over there . So you were in the administration, the project, uh, tub and I can click on that. And the first step is now to update the project to use the new permission scheme. So let's go ahead and do that, and you can go to permissions and you can see that it's using the default software scheme. So all of this is being assigned to any logged in user as we had seen before. So I am going to goto actions and use a different scheme. And here I'll select the main software scheme that we just created. An associate that to the project. Now you'll see everything has been updated to project role project team so on and so forth . So not this project is using that new scheme. What is the next and final step is to assign the right people to the project rules. So every project injera will have the project rules that have been configured. So you can see here that by default the administrators and developers of our even set up because we added your developers to the developers project rule so automatically that group is assigned and given privileges for the developers project will. However, we didn't really end up using this product rules in the permission scheme. So what I'm gonna do is I'm actually going to open up the permission scheme in a separate tab just so we can keep track. If it now, I'm not sure why. It added the administrator under developers. I think this might be a bug in here because I noticed when I was playing around it myself. Um, I noticed that when I created a new project, but I did not generate any sample data. It never ended up adding the administrator into the developers roll. But whenever I create a project with sample data, it does this, so I'm not really sure why it's doing them with sample data. I don't really need the administrator to be in the developers project role so I can go ahead and delete that. All right, so now, looking at the permission example, you can see that Ah, the project owner and project ah team are two of the main ones that we need to configure as well as consultant. So let's go ahead and do that so I can go to ah, to add a user to roll. I would need to go up here and I can click on that. And the first thing I'm going to do is select the product on our project owner. And I believe that was John Smith and I will a John Smit to the Project Owner Project role and click add. So now you can see the Project Owner Project role has John Smith, and then I would need to add the external consultants group to the consultant project role . And then finally, we need to add everyone. So let's look at external. We don't want customers because we don't want customers to have access to everything that the project team conduce, so we'll add external consultants will, we will add John Smith and we will add the Jura Developers Group all of them will go into the project team because all of them should technically have access to the basic functions , like creating issues, viewing issues, assigning issues, things like that. Now notice how customer is not in this project role. So what we need to do is we need to add the customer to be able to browse projects, but nothing else, because obviously we don't want. We want the customer to have read only access. So let me go back to if I need to edit this permission. This is going to take me from the Project page back into the issues Permission schemes Page , and it's the man software scheme. So I need to go in and click, edit and add the customer project rule to this permission scheme. And then that's that. And then I can go back here and then I would add the External Customers Group, and I think this is case sensitive, which is why I never gave me those. So I needed e within with a Capital E over there, and so external customers will go to the customer project will and I believe that. Is it technically, actually, I just realized that I didn't really need to create. Actually, it's fine. Yep, creating the consultant project will make sense and adding, certainly consultants, and that is all we needed to do here. So let's now stop this video and we'll go to the next video, and we'll actually now test each and every one of the users and make sure that everything lined up correctly. 33. Roles and Permissions Example - Part 3: Let's now test out the example scenario that we just configured in the last video. And, ah, we will actually go in and log in as each and every one of these users and make sure that all these objectives or requirements are satisfied. So before we get into that a quick summary. We created a new permission scheme, and we modified it to assigning to these permissions different project rules. And you can see that we're pretty much using each and every project role that we've created . We've used developers and consultants. This is the only thing where the action where we've actually used this project rule and we're only allowing them to view the development tool section we have used customer and that this the only thing that they're able to do is just to be able to see the project and issues, but nothing else. Obviously, the Project team is the main group here that gets to work on issues, and the project owner gets to manage the project as well a sprints. So Pence. Given that we're using all project rules, it's important to make sure that each and every project rules have the designated users within them. So for Project Team, we put in the consultants. Developers in the project owner. The project on her self explanatory developers have the developers, customers, consultants one and so forth and then administrated administrators are there by default. So it looks like we're good to go. Now let's go in and actually test each of these users out. And maybe we can start off with the consultant. So when we log in as the consultant, we're expecting that the consultant can Onley see this new project we created is able to edit and work on issues, even create issues, but cannot do things like managing a sprint. So let's try that out. So we'll go back here and go to user management and we will look at the consultant profile and let's log in as that user. Maybe I want to open this up in a new Tapia, Um or not. Okay, so now we're logged in his Richard Hendricks. So the first thing we would need to do is let's go to view all projects. Uh huh. So we can see all the projects. Now I wonder why that's the case. The purpose was that they can only see this new project that we created. So let's switch back to the administrator account and take a look at this. And I think I know what's going on. Let's go back to the issues permission schemes. Now they converge. You these projects remember how these projects were using the default software scheme, which really has no permissions. Ah, are no real security being enforced? Because Anne logged in user can browse projects. So in order to restrict that access, we would need to come in here and we would need to actually first, let's remove the any logged in user permission access and let us add, um, you know what? Maybe let's just add the project ing, but then again, for all those other projects, no one's really been assigned to the project team. So technically, maybe you could just add the Jeer Software Users group, and maybe I'll just do that. For now, however, it's not best practice. I would recommend to use project rules all the time, and then you configure each project and a sign people or groups to those project rules. But we'll just keep this for no, because we know that the consultant and customer. They're not part of this group. Ah, And also, one thing I realize is if we want to restrict the consultant toe only work on issues for that given project that's not gonna work because you can see that things like assigning issues for the other projects, even creating issues. I think this is missing here, but we so, for example, are And let's just update create issues and take a look, um, create issues. I'm going to do the same thing and give it to jeer software users so that consultant and customers are not able to create issues in these other projects. So hopefully that should take care of some of the stuff. Now let's go back here. Go back to user management. Simon, open Richard Hendricks, profile in a new tab and let me log in as this user. So now when we go to browse all projects, we should only see one. And there you go. So we have blocked access to the other ones and we have assigned the browse projects permission to consultants. So which is a part of the project team and so they're able to see the project so that requirement has been satisfied. Now let's go into the project. So I'm logged in. Is Richard still? And you can see that I can click and drag issues so I can pretty much work on issues and change them around? I could go into the details, and I can comment on them by clicking on the common button. Ah and ah, so it looks like I can work on issues. However, I can't complete the sprint so I can't manage the sprint and says that I don't have the management permission. And if I go to the backlog, I can create a sprint either. So it looks like it's set up correctly the way I wanted. I'm able to see the project. I can work on issues. Let me see if I can create issues I should be able to and should only be for the one project. Yet That's perfect. So looks like things are working s so I think we can now log out of this user's account. Now let's check out the project owner because we saw that the consultant wasn't able to start or manage sprints. So now let's go in as John Smith log in his users. So obviously, John Smith is part of the Gear Software Users group, so he has access to all the projects and can view all the projects. But now the main thing I want to check here is that the create spring button is available, and I can create a sprint if I want to. So looks like John Smith has the correct privileges. And if I go to the active sprints, I can complete the sprint as well. So perfect now. We also mentioned that the project owner can administer the project. And if I go back here, let me just go back to jeer administration for one second here. Oh, I'm logged in as John Smith, so never mind. I'm just going to leave that for now. But that's interesting. You can see that John Smith can administer projects. He is not able to see any of the administration options because he's not Ajira administrator. But we set him as the administrator of the project so he can go in, and this permission example project is the only thing that he can really administer, and he can go in and he can modify the users and the roles or the users that are assigned to which roll over here. So it looks like that part of the requirement is are already and also of insect. So look, so far, so good. Now, let's Ah, I guess let's take a look at the developer account. So I'm going to switch back here and the thing I wanted to show you before. Ah, and let me just show you that quickly right now. So if I go back to issues and I take a look at the permission schemes and look at the main software scheme, you'll see that the project owner was given the administer projects permission, which is why John Smith was able to administer that project alone. So that's good. Now let's go back to users and let's go in as Thebes developer log in his users. The only difference really between the developer and the consultant is that the developer is able to see all the projects because they're part of the Geo Softer Users group. So yet that's good. And just to confirm, I can go into the permission example Project and I can drag issues and update them as well , and I can create issues. I should be able to create them for every single project. Yeah, that looks right. So that's perfect. So let's switch back to the men. And the last person we need to verify is the customer. So this will be interesting. So I'll click on Ehrlich. Let's log in. Is Ehrlich all right? So the first positive sign is that the create button is missing, so I'm not able to create any issues. If I go to view all projects, that's perfect. I'm only able to view that one project now. If I click on that, let's see what happens. So it takes me to the sprint board and you can see that it's not letting me drag it to any one of these columns. So yep, it's saying that something is preventing me from doing that. If I go into the details view and if I click on this Ah, is it able to my able to comment here So it looks like I am able to comment. So I wonder if I made a mistake with the permissions. Perhaps I added, let me actually close this and open up this window in in Utah. So it opens up the issue details in a new tab, and you can see that the, uh, the edit buttons and all the buttons up here in transitioning the issues they're gone. I'm not able to really click on a sign e or do anything. I could start watching the issue. That's not a problem. And, yes, over here I don't see a comment button, so I'm not able to comment on this particular issue. So this is the pep 11 issue. So if I close this and let me try refreshing this page and if I click one of these tabs, yes. So the comment button does appear over here, so that's interesting. I wonder if that is, Ah, bug Guajira. So let me try to put in a comment for Pep. 15. So this is a comment from a customer. Add up. There you go. The juice ever could not be contacted, so it looks like there is a problem. Even though it's letting me, it's showing me the common button. It looks like it's not really letting me comment, so that's good. Um, I can cancel that, And if I go into this issue details that common button shouldn't appear it. Yes, so there's no way for me to really comment. It looks like I have read only access. So this is perfect. I think things have worked out exactly the way we wanted. Hopefully, that example has shown you the different ways that you can configure users. But more importantly, demonstrated how you can take advantage of project rules and permission schemes. So once again, the permission scheme is where you define the permissions, and that is how the permissions get mapped to a project. When you create a project, obviously it'll end up going into the default permission scheme. But you can associate the one that you really want to use for that project, and then the Thebe best practice is that for every permission to associate that permission with a project rule, and so that's kind of kept generic and then going forward for any project you create, you can decide which user gets to adopt that, or each and every product roll and get access accordingly. So that brings us to the end of the users groups, Project Rules and permission section. So now we're gonna move on to some other administrative work and other things injera that we can configure 34. Understanding Jira Schemes & Introduction to the Schemes Example: We have spent the last few lectures on permissions and seen that projects have all the project rules that have been configured injera, and it's up to you to determine which users go into the project rules for each of the projects now going beyond roles and permissions. Projects also have many other items that you can configure, such as issue types, fields, screens and work flows. So let's start taking a look at them one by one. And once again, I think it would be best to use real world use cases as we go through them. So basically, you can configure each of these things and assign them to projects based on schemes, just like the permission schemes that we've talked about before and saw That permission scheme is what associates a list of permissions to a project. So similarly, we've got issue types and then issue type schemes, which linked the issue types to a project just as an example, or, in other words, the issue type scheme tells us what issue types are available for us within a project. So let's look at how gear connects all these things together. Julia has some default issue types like story epic tasks, etcetera, so you can go ahead and create your own issue type and then issue types get grouped together and form an issue type scheme, which then gets mapped to a project. Similarly, you can create a custom field and year gives you many options of different field types. So ah, so that you could create things like text fields, drop down state pickers, even a user picker and so on. And you can create your own field of any of these types. Once the field is created, you would need to, obviously, state which screen that field will show up on. You can also set the behavior of the field. You know, things like Is the field mandatory or not? Or perhaps it's a hidden field, and this is done in a field configuration. This field configuration is mapped to an issue type through a field configuration scheme, which being a scheme means that it gets mapped or assigned to a project. So, for example, you could create a field called Urgency and you assign it to a particular screen. Then you can specify that the field is mandatory in its field configuration, and then finally say that this field configuration only applies to certain issue types and then associate that to a project. And then we have screens that you see when working on issues, and you can basically create your own screen. Now there are three different ways. Start three different ways. You can see a screen, whether it's creating an issue, editing an issue or viewing an issue. So these air what they call operation types and so you can create a screen and then conspiracists I which operation it should appear for. And this is done using a screen scheme. This screen scheme then gets mapped to an issue type via the issue type screen scheme, which finally gets assigned to a project. I know it might seem a little confusing now, but it'll all make sense once we go to the example. And ah so just to give you an example in theory, So for, say, I want to create screen A that will appear when I create an issue of the issue type Story four, Project eight. You can do all this through these screen configurations. Screens can also be mapped to workflow transitions. So, for example, when I transition from an in progress state to a done state for a particular issue. I can prompt for a screen to appear in case I want the user to fill something out whenever that transition occurs, such as filling out a field called implementation details of what the developer did when making or marking the ticket has done, which then brings me to work clothes. We've already seen this in previous examples, and it basically defines the series of status is that an issue can have and transitions that it can go through. Between these statuses, you can create different work flows and map it to issue types. So different issue types can have different work flows. And this mapping is done in a workflow scheme, which, as usual, will get assigned to a project. So we'll be going through these one by one by building the following example. So we'll first start by creating a new issue type called Spike. Now, what is a spike? You may have heard of it. It actually exists in some types of agile methodologies, like extreme programming, and basically represents a ticket that involves research or investigation or design. Basically something where you would need to gather information. An example would be having a feature request that can't be estimated because you would need to do some research on technology or feasibility of the request before you can actually work on it. So this issue doesn't exist. Or this issue type doesn't exist in jeer by default. So we'll be creating one as an example. We're then going to add that spike issue type to one of the projects that we've created in this course, and then we'll create a screen for that issue type map, the various operations through the screen scheme and then map that screens came to the to the issue type to the issue type screen scheme. Then we're going to create some custom fields for the new screen. So, in particular things like, ah, spike type So we can create this as a drop down field and it'll have options of investigation or research. You know, what kind of spike ticket are you creating? Will have a field called spike results, which is a text field thes. The user can just put in the information that they collected as a result of the spike, and then we can put in a high level work effort estimation. Now, obviously the world is yours in terms of what feel do you want to configure for the issue types that you create or the screens that you create? But we'll just use these as an example, and then we'll also walk through the field configurations and their schemes. And then finally, the work flows. Now this is a major feature, an aspect of Ghira that makes it so customizable and dynamic toe work with So First will modify an existing workflow that exists for an issue type that's already being used within the project will make sure that we go through the agile board to map these workflow changes to that board, because I don't believe we've done that yet. So that's something that's definitely important. As you configure your workflow as you add new status is potentially you want to make sure that they get mapped to the agile board columns. Then we'll create a new workflow for this new spike issue type that we just created, and we'll talk about some workflow transitions and general other tips and tricks or things that would be worth knowing about work flows and that would bring us to the end of the example. So just to show you where all these things get configured coming back to my Geo instance, all of these can be seen in the issues top of the administration page. So you've got issue types, workflow, screens, fields, and that's pretty much covering everything all the core pieces of Ghira while working on issues. So we're going to start off with issue types in the video, and then we'll go to them one by one. 35. Configuring Issue Types: here we can see the default issue types that gear has. We've got bugs, epic stories, tasks and sub task and notice that the sub task is of type sub task, whereas the other ones are a standard type and you can see the related schemes that they're all a part of. So what we are going to do here is create a new issue type. So if I click on add issue type here and let's call this a spike and we wanted to be a standard issue type, not a sub task type, so you can add in a description if you want, but let's just go ahead and click, add. I mean, it should show up here. Now, I'm not a huge fan of this gray icon here, so I'm going to edit this and you can select a new image. You can either choose your new avatar, but I will just pick this question mark here just cause it's ah, you know, it involves research. You don't really know if you can work on a feature until you do the spike. All right, so we have created the new issue type. Now let's ah, go ahead to the issue type schemes because the next step is to group them together and make them available for a project. Now, under the issue type schemes, you can see here that there is a scheme pretty much for every single project that we've created. And this is something that Ghira does now is that they create a new scheme for any project that you create. Um, this could end up being a little, ah, redundant in the sense that if all your projects end up using the same issue types or in general, same schemes across Zira than every time, it's just using a different scheme. And so if you want to change something about a particular scheme for all the projects, you have to go in and do it all one by one. So there's a way that you can actually bypass this, and I just want to show you this for a quick second. If you want to avoid having to create or if you want to avoid gear from creating a different scheme, every time you create a project, when you create a project, I just want to show you this quickly. You have an option of create with a shared configuration. And what this does is it takes all the configuration for an existing project and maps it or assigns it toothy existing project for the new project that you're trying to create. So, for example, if we use the permission example project for which we had to find a new a new permission scheme So if you just select that and it next, then you can fill out all the project details and it's a mint, and it'll create a project with the same scheme configurations. So I just wanted to show you that for a quick second. And ah, so now let's create Ah, What I think I'll do is I'm going to end up using the permission example project that we created in recent videos, and I'll work on this project. So if you wanted to create a new issue type scheme, you could just click add issue type scheme you type in your name, you can type in a description. You can specify what the default issue types gonna be, but only once you select which ones are available and then So these are all the available issue types you can see Spike, the one that we just created. So if you want to create a project, for example, where you can only create spike tickets, you would just need to come in here and move spike into their and then obviously the default would be Spike. Ah, if you have more issue types available within that scheme, then you can specify what default ticket you are. Different people issue type you want selected. So that's how you would create a new issue type scheme. But given that now we're going to be using this project which already has a scheme with these issue types, I can just go in here and I can edit this and I'm going to just drag despite ticket into here as well. And then I'll Ah, the default issue type being story is fine, so I can hit save. So now that I have saved that scheme, which is mapped toothy, uh, where's a right here to the permission example project. Now, when I create an issue, I should have the option of making it a spike issue. So let's just try that, uh, I'll open this up in a new tab, and so I'm going to select. I don't see the permission example project here. And you know what? I think that's because I never I'm logged in as the administrator, and I never assigned the administrator to the project team role, which is why I'm not able to really create or work on issues. So let me die aggress for just a moment here and let me give myself permission. So permissions. Uh, no, it would be the project role. So I need to go to projects and permission. Example project and let's go to roles. So I'm logged in as cautious car administrator account, and that's not part over here. So let's add uses to roll and going to select my men account, and I'm going to assign it to the project team and then at, and that should do it. So now if I go ahead and try to create Yeah, There you go. Now I can see the permission. Example project right there and here. You see, Spike ticket available. So there you go. We have just created a new issue type we created, or we modified an existing scheme to add that issue type to the scheme so that it's available for the project that that scheme was assigned to. So coming back here, we've taken a look at issue types. We're going to skip work flows and visit that right at the end, and we're going to move on to screens now. 36. Configuring Screens: were no moving on two screens, So you can see here that these are a list of screens that currently exist in my Jura instance. And ah, a lot of these screens are specific to the projects, and you can see a common similarity between them in that when I created a project given that it was an agile scrum, Bia's project Jiro automatically created a bug screen, and a default issues green for each of these projects. So the one that we're working on is pep, and so you can see it's got a scrum bug screen, any scrum default issue screen. So if you take a look at one of them, you'll see that it's got a list of fields and the respective order that they show up on the screen. So what we're going to do is we're going to create our own screen, and instead of going about it, Lissa, if you hit add screen, you can put in a name, and then it will take you to that screen page, and you would have to add fields one by one, starting from a blank slate and basically configure that screen to, you know to to determine which or to set, which feels will appear on that screen. So to make things easy, what I'm going to do is I'm going to actually copy one of the screen so that the fields that have already been configured will end up on my new screen for these bike issue. So let me go ahead and copy the pep scrum bug screen, and I will just need to adjust the name here, so I'll call it Scrum Spike Screen. And when I hit copy. So now it adds the spike screen there, and if you go into configure, you'll see that all the fields are automatically there by default. So now in order, remember how I said that the's screen scheme and you can see that the spike screen doesn't have a screens came just yet, but the other ones do, and the screen scheme is where you can map a screen to an issue. Operations such as create, edit or view an issue. So in order just, for example, purposes. Ah, normally, this doesn't exist because usually the same screen is used for all the operations, but just, for example, purposes if we have to demonstrate a different screen for, you know, two of these operations than I would have to create another screen here. So let's just assume that the scrum spike screen is what will use when editing and viewing a spike issue. But for create screen, I'm going to create a new one. So this time I'll just copy the scrum spike screen. I'm going to call it the scrum Spike, create screen. Oops. I forgot to remove the copy over there, so I think I'm going to yet it's at the top years. I'm gonna edit that and I'm going to remove the copy off and hit update. Okay, so now it's down here. Now let's go in and configure this and let's make this look a little different. So I'm going to simplify this. And I think that makes sense because when you're creating a spike screen, you just want the bare bone details and then when you're editing it, perhaps we can show more details. And obviously this is just, for example, purposes. So I'm not paying attention to, you know, reasons for keeping some of these fields year or not, eso will keep a summary, maybe the issue type. I'll move it over. The summary will remove the reporter. Components will keep the description. Don't need a fixed version. Priorities Fine there will remove the labels and all this other stuff don't really need. The assigning is probably important. We'll just move that above priority, and then we'll remove the rest. So we have three fields here or sorry, five fields here for the scrum. Spike creates screen. All right, so we've created the screens that we want for the new issue type. Now let's go ahead into the screen schemes and actually map them to the issue operation. So here you've seen that once again, Jura has created the default screen schemes for each project. So we're going to be working on these two. So let's go ahead now and create our new screens scheme. So I'm going to call this the Pap scrum spike screen scheme. Just ah, keeping the naming convention consistent and the default screen. So we do need to provide a default screen. I'm going to call that the scrum spike screen here so we'll add that in. So now it takes us to the scrum spike screen scheme page, and here you can see that by default the scrum spike screen will appear the first green that we created and this is used for all the unmarked operations. So if we want to map in operation to a specific screen, we can go here. So associate an issue operation and I'm going to say for the create issue operation, I will use these scrum spike creates screen. So I had ad So now it tells me that for the create issue is going to use the create screen for everything else. It's going to use the regular spike screen and that's it. So if we go back to screen schemes here, you can see that the scrum spike screen scheme has been created. Now the next step would be to map it to an issue type screen scheme because right now we haven't yet mapped the screen or the screen scheme to the spike issue type. So let's go ahead and do that here and so again, these air the screen schemes issue type screen schemes that have been created for all the projects. So the one that we're working on as this one, which you can see, has already been mapped to the permission. Example Project. So all I need to go in is or all I need to do is can hit, configure and you can see. So remember how we saw the two screens that were, uh, that we or that were created So you can see that the bug issue types mapped to the Bug Screens game, which contains the bug screen. And then all the other issue types have the default issue screen. So what I need to do is associate a spike with the spike screen scheme that we created, which is right here and then hit ad. And there you go. We have just configured our screens that we want for the spike. So let's work back for backwards and go through them again. So we have a scrap ah Pap scrum issue type screen scheme, which maps a spike issue type to this screen scheme. So if I go into the screen scheme now, this screen scheme tells me that if it's a create operation to display the screen, if it's any other operation to display the screen, so that's kind of how it works. So let's go ahead and actually verify and test and make sure all of this work. So I'm going to hit, create, and I'll just pop that open in a new tab. And ah, you know what I'd rather use? I'm going to cancel out of this and I'm going to go back into searching for issues. And the reason being is because when I'm on this page when I hit, create, it actually gives me a pop up, which is easier to work with. So let me hit, create and there's a pop up. And the reason being is I can just switch the issue types and all these fields will automatically update, So it's easier for us to look at. So you can see that this is the screen that people see when creating a story within this project. No, If I want to create a spike ticket, notice how it got simplified and you see the five fields that we had configured. So there you go. So let's just create a test spike ticket and we leave all all the rest blank. So we'll go ahead and create that, and I wonder if it will show up here. No, it doesn't show up there, so let me just filter by permission. Example Project. And there it is. So if I go in here now, when I click edit, you'll see that a lot more feels show up because this issue operation is mapped to the default screen, which contains a lot more feels. So there you go. We have just created some screens, and we've set different screens to appear for the operation type. And we've mapped all of that to a new issue right to a different operation. And we have mapped all of that to a new issue type that we just created. So now we're going to try to build on these screens by adding some custom feels. 37. Configuring custom fields: in this video, we are going to create a couple of custom fields. So in order to add a custom field, you would go to the custom fields page and then just click on Add custom Field. And here you can see the different field types that year has available. So you have check boxes, date pickers, um, all kinds of things. Radio buttons, a select list or, you know, text field, whether it's a single line or multi line, a euro field or even a user picker, which would select all the or it would give you suggestions of all users that have been configured or created India. So the first feel that we're going to be creating is a spike type, which I think would be best as a drop down menu. And so we'll click that and hit next. And let's call it these bike type can add a description if you want. That actually appears when you're creating a knish, you it appears right below the field and the option. So given that it's a drop down menu, the options are going to be either a research spike type or an investigations by type and maybe we can just set another option for something else. So we'll put that in and had create. All right, So now once I've created the field, Jura asks me to perform a re index as a configuration. Changes were made, and you can go ahead and do that. There's a way you can do that in the background. Um, so I'm just gonna close this for now. Eso by just clicking on that re indexing it will take you to the re index page. But let's just finish creating all our fields first. So after created that field, it's going to ask me what screens do. I want to place it on. So we want this to show up on the scrum spike, create screen as well as these Graham Spike screen and let's Hit update. And so that's done. And it will show up right there, and it's a select list, and it's given some details of the screens that it's on. So there you go. Let's add a couple more custom fields, so the next one we want to create is the spike results, and that I think, would be appropriate as a multi line text field. So Let's call it spike results. You can put in a description so information collected as a result of the spike and had create. And again it's going to ask me to put this on fields. And this time you know when you're creating a spikes being, you don't have any results, obviously, so there's maybe we'll skip adding it in the create screen. We'll put it on the normal spike screen. So hate update and the last one we're going to create is the work effort. And again, this is just, for example, purposes. I think we'll use a single line text field. Or actually, maybe it's better off doing a select list because we'll give options of the work effort. So So, um so let's call work effort and the options are going to be, You know, it's a small task or medium or large. So as a result of doing the spike, you know, saved some investigation or research, it's determined that it's a large effort to work on that feature quest as an example. So there you go and I'm again. I'm going to address only to the spike screen because that you'll really only know after you created the ticket and have worked on it. Okay, so we've created the spike feels then you feels that we want to create. Maybe we could do a quick demo just to make sure that they're showing up. So if I had create and under the permission spike, so you see that spike type automatically got added to the screen and only spike type issuing up. So there are the options. And if I ah, if I go to living, cancel this and I go to the edit page, you should see the spike results and the work effort. So there you go. That's all working. And it's, um, it's come together so that it's that easy to create a custom field. Now let's talk about the field configurations and field configuration schemes. Say, for example, you decide that for any spike ticket you want to make sure or you yeah, you want to make sure that the Description field and the spike type fields are entered, so you make them mandatory. The user has to enter something in, but only for a spike type ticket for this project. So here, that bad you would do under field configuration and the field configuration schemes. So here in jail, you can see that there's only one default field configuration, and this is something that isn't actually very common. At least I haven't seen it happen a lot within teams, but because usually you don't enforce mandatory fields, but there can be a situation where you absolutely will have to. So in order to do that, you would have to treat it in. You feel configuration because if we go into the default field configuration, you'll see that pretty much all the fields appear here and on the right of each field, you can you can. You have your options of whether you want to make it a required field or you want to hide it, and you can even modify the renderers. So if it's a text field, you can adjust and set what kind of render you want for that text field, for example, and it gives you the screens that the field is on now. If I go in, for example, and I make the Assign me field O. R. Maybe that's a bad example. Let me go down. Maybe the yeah, the description we were talking about description. So if I go in here and I make the required field, if I click on that, it's going to let me just do that. Just an example. I'll undo that change and I go back down. You see that this is a required field, so I'm just going to turn that back into optional now. The problem with that is every single project right now is using the default field configuration, and I can show you that quickly. If I open up projects in a new tab and I go into the permission example, Project and I go into feels, you'll see that it's using the default field configuration. So if I go in and I make that description mandatory than any issue type that I create or edit or any screen that I C. By default, that description field ends up being mandatory. So I obviously don't want that, and that will end up happening for every single project because every project is using that default field configuration. So what I have to do is I have to create a completely new field configuration. If I decide that I want the Description field to be mandatory Onley for spike tickets within a specific project. So let's go ahead and do that. So I click Add field configuration and I'll just call it the new field configuration and then click Add. So what that does is it automatically creates a field configuration with all the fields in there and here I can go in, and I can specify that the description is required, and I can also specify that thes spike type is required. So now that that's complete, you go back to view all field configuration, so that's been created. Now the next thing we need to do is we need to map it to an issue type so that is done here in field configuration schemes. Now this is interesting because gear tells me that you do not currently have any field configuration schemes configured. But the fact of the matter is that behind the scenes, Jiro does use a field configuration scheme because if we go back to the permissions project , you can see here that it's a system default field configuration, so perhaps they're not showing it because they don't want people or get they don't want to give users the ability to modify it. But there is a behind the scenes default field configuration, which is mapped to the default field configuration set up that we just saw. But this is the scheme like they do have a scheme that they use and you can go in and you can use a different scheme. But obviously when I click on that, it says there are no other schemes configured, so you can't really switch to that. So if we go back here, we'll we'll need to do is we'll need to add a new field configuration scheme and let's just call it the new field configuration scheme. Click, add, and so it automatically takes me into the page. So if I just click on this again, you'll see now that there is a new field configuration scheme. And when I go and configure, this is the page that it took me two. And it's saying that basically all the issue types will use the will use the default field configuration, but we don't want this or basically that's OK for all the other issue types. But for the spike, we want to use the new field configuration, which we just created because that's where we set the description and the spike type to being mentor. E. So there I have mapped the field configuration to an issue type, and now the next and final step would be to go back to the project permissions and state that I don't want to use the system defaults scheme. I want to use the new scheme that we created so now is using the new scheme, which is mapped to the new configuration. And basically, that has something different for the that that uses the new configuration for the spike ticket and the default field configuration for all the other fields. And so if you click on default, it expands it out. So and if you click on you, feel that expends it out and you'll see that the description is required. All right, so now let's test this out. So again, I'm going to go to the search for Issues Page and let's create a ticket or issue so permission. Example Project. I have spiked. You can see that description is mandatory and the spike type is also mandatory. So if I put in research for that and I had create, it obviously tells me I need a summary so I could just call it test despite two. And also descriptions required. So it's still won't let me created until I type something in there. So let me say this is the description Pan let's head create. So now I'm going to select the permission example project. And there it is. Ah. And so there you go. Now, if I go and so I create, but I pick a different issue type. The description field, you'll see is no longer mandatory. And the spike type isn't even there because we never configured it for the story issue type . So there you go. So that's how you would create custom fields. And if you want certain feels to be mandatory, you can do that by a the field configuration. 38. Creating a new workflow: we're now going to be taking a look at work flows, which happens to be one of jeras most important and core features that make it so dynamic and customizable. So you can see here I'm in the work flows page under the issues tablets again and these are all the work those that have been set up and basically Jura created a different workflow. They're all pretty much very similar because these are for projects that were created. Ah, using the agile scrum BS methodology. So a lot of these were close air. The same with one that we will be using is the software simplified workflow for Project Pap , which is the project we're using and you can see that it's got in a sign scheme. So let's take a look first at this workflow. When you go into view it, it renders the workflow in two forms. You can view it as a diagram or as text as well. So the diagram obviously obviously shows you these statuses and transitions for your status . And in this case, it's telling me that pretty much all statuses can transition and to each one of these and there are three status is being used in this work will, if you want to see it in the text format, basically list for each status. Ah, what the transitions are, and you can view properties of them to view the properties. In the diagram, you can click on a transition. So right now it's not doing anything because I'm not in edit mode. I'm just viewing, so I'm not really able to see that. But this gives you, Ah, high level. Look at what a workflow looks like. Now let's go back to the workflow page and you can see that it's using this simplified workflow scheme for the pet projects. So let's click on that so it will take me to the workflow schemes page. And this is the work close game that's being used for the pet project. And you can see here that basically all the issue types, all on a sign issue types. And given that there are no issue types specific ones that are being assigned to a specific workflow, it basically implies that all the issue types are going to use that workflow. And if you go toe workflow schemes, this is where it lists all the workloads schemes, and you can see that this pep where close scheme is being used by the permission example project And it has this software simplified workflow, which we saw in the workflow page. So we can click on that and it takes us back to the workflow. So what is our goal now? Our goal is to create a new workflow for the spike issue type and will also eventually make modifications to this default workflow scheme that's being used by adding more statuses so on and so forth. So the first step is, let's create in you work for for the spike issue type. So I'll click on add workflow. And let's call this thes bike issue issue type work Phil, and we'll hit ad. Now it automatically brings me to this Ah, where it's got a default, create transition and a default status that it goes to. Now I'm thinking of a spike workflow, and I would think that and imagine that it would just start off as a to do item. Then a user would start the spike ticket and would go into in progress, and then, once the research or investigation is done, the ticket would be marked as done. So what I'm gonna do is I'm not going to use open. I can go in and I can add Certain status is now if I click on open, you can see here that these air the property, you can click on properties. You can allow all statuses to transition to this. And ah, if I try to remove the status, it's going to say that the initial status cannot be deleted, so I'll need to go in and add status. And here is a list of all these status is available in JIA. Now you can create your own, and that's something that you can do over here under the issue attributes statuses, so you'll see the same list of statuses and you can create your status is there. Now what I'm gonna do is so Jura has the to do said it. So let me use that and I can specify to allow all statuses to transition to this one. If I do that and add it, it basically has this all going into to do. But let me just remove this transition for no. And now that I have another status I can take the create transition right off the bat, and I will map it to the to do status. And now I can go in and I can delete the open. So they're now. Every time a user creates a ticket with this workflow, it'll go to to do now. The next thing I want to go and do is add the in progress status because that'll be the next status and I'll bring that here. And instead of allowing all transitions to transition into it, I'm going to do a specific transition. Um, and I can call the transition whatever I want. So maybe I can call it Start Spike, because I know that it's going to be used for spike tickets. But you know, you can keep that generic. You can just call it start progress or start Dev or just in progress. You could just mimic the destination. Progress name. Ah, status name. Sorry. And so let's call it start spike. For now, you have the option of displaying a screen. So every time the transition occurs and we mentioned this briefly in the past that you can map a screen toe, work will transition so This is where you can do that, but I'll keep things as none for no and hit ad. So it added that transition from to do to in progress and the last transition I'm going to add is for the done status. So click, add and then bring that in here. And then from in progress I'll go to done and I could just call that done and that's it. So I created the workflow. Um, I can drag it around and kind of centered on the page, and so that's it. That's the workflow. Now let's go back to the work flows page, and you notice that that spike issue type work low is not showing up here, and this is where all the active workers are. The reason it's not showing up is because we haven't really done anything with that workload. We've just created it, but we haven't assigned it to any project or any scheme or anything. So it will actually show up here under the inactive work clothes. And there it is spike issue type workflow. So the next step for us is to make it active, and so in order to do that, we need to assign a scheme to it. So let's go toe workflow schemes and we want it to apply to a spike issue type for the permission example project. So we need to go in and we need to edit this scheme So it's going and click edit now. As we saw earlier, all the unassigned issue types are being mapped to this one. So what we want to do is let's add a workflow and we'll add an existing one because we created one. And there it is at the bottom over here, and you can verify that that's the one you created hit next. Now it's gonna give you the options of what issue type do you want a map to it so we'll select Spike and we'll hit finish. So now you can see that thes spike issue types will use the new spike workflow, and everything else will use the default one that exists now. Don't forget to hit publish. So once you had published that will actually save the changes, had associate gear, goes ahead and does the migration shouldn't take too long and then hit acknowledge so that saved. Now if you go back to the work clothes. You can see that now the spike issue type workflow is active, and it's being used in the scheme that's used in the PP project, and you can view it just to confirm. And there you go. So that's the new workload that you created. Now let's just spend a minute and verify these changes that we just did. So I'm going to go back to searching for issues, open that that up in a new tab and let me filter by the permission example project. So now you can see I have the a spike ticket selected and the status is to do. And when I click on view workflow, it shows the new workflow that he created. And if I select a story instead and look at the workflow, it's using the other default workflow that it was using before. And so if I go back to these bike ticket, you'll see that this is to do so. The only transition that's possible now is to start the spike, and when I click on that, it's going to move it to in progress. And then the last status we had was done, and the transition for that is done. So if you remember, the transitions are all represented by the buttons that over here and the name of the button is basically the name of the transition that you created. So if I hit done and I'll update the workload to done so there you go. We just created a new workflow, and we assigned a particular issue type water project to that workflow, and we have just gone in and verified and run through that work alone. We have seen how the different issue types within the project are all using a different workloads. Now let's go into the next video and see if we can actually modify and add more steps to the to the existing default workflow that the other issue types are using. 39. Editing an existing Workflow: Now that we have taken a look at how to create a new workflow, let's look at an existing workflow and modify it to add some more steps. So I'm going to be using these software simplified workflow for a project pep, which is what all the other issue types except the spike issue type is using. So if I go into view, you'll see that it's a fairly basic workflow where all statuses can transition to any other status. So what I'm gonna do is I'm going to click on edit now whenever I click on editing a workflow. What it does, is it. I am not editing the actual life workflow as the issues air using it. What it does is it creates a draft workflow, so a copy of it set a copy of it, sets a to draft mode, and once I'm done, my changes. I can publish that draft so it replaces the current workflow with this knee, one that I've just drafted up or I can discard the draft. If I'm not interested in keeping the changes and while I'm making the changes, I can always view the original to compare my changes versus what's being used right now, So let's go ahead and now start making some changes here. Just going, Teoh, reorganize these things now. I don't want to have all transitions being able to transition from one to another. So I'm just going to go in here and I'm going to delete all and instead off Ah, having all go into these transitions, I'm just going to have a ah, more specific transition. So from to do I'm going to go into actually no, not done. I want done to show up after in progress and from to do, I'm going to go into in progress. And ah, So since this is related to development, I'm just going to call this start Dev and hit at Now Joe gives me a pop up warning or air message saying that I cannot perform this operation on a draft workflow. If I click on this link, it will take me to a page. And it'll basically tell me that Gira restricts you from editing a life workflow. Ah, for certain kinds of edits. So being able to transition or adding new transitions to an existing life state, um, and adding statuses, various things like that you're not allowed to do when a workflow is life. So then how do you go about editing a workflow? And adding new status is Well, what you need to do in that case is you need to make that work flow the one that you want to modify. You need to set it to being inactive. So there are no issues associated with the workflow. And only then you can make these more in depth changes to the workflow. So if you make the workflow inactive than what happens to all the issues, well, that's what we're going to go to. So I'm just going to discard this draft and I'm going to go back to the work flows page. Now, what we can do here is you can see that this workflow has a copy option. So I'm going to create a copy off the workflow, and I'm okay to call it the copy, and I'll just hit Copy Now what that does is it copies the workflow. It takes me to that specific work full page, and it's exactly the same. So and that's exactly what I want. So now I go back to work flows again. That copy is not showing up here because it's not been assigned to any project or scheme. So it will show up here under inactive, and there it is. So what I need to do now as I need to go into this workflow scheme, and I need to tell the scheme to use the copy instead of the main one that we want to modify. So here I'm gonna add workflow again and look for the copy, which is right there and looks exactly the same, which is great. And I hit next. Now what I'm gonna do is I'm going to select all on assigned issue types. So previously, all on the side issue types were using the one that we want to change the main workflow. But by selecting this, it's going to basically replace that one with the copy, because you can have to work flows both being mapped to all the unassigned issue types. You can only have one. So hence by selecting that it replaced the previous one so I can go ahead and publish and associate, and it's gonna go ahead and make those changes. And you had acknowledge So now the workflow being used as the copy. So if we go back to work flows, you'll see that the copy is now active and the main one that we want to modify is inactive . So now we can go in and we can make the changes that we want to. So I'll click on up. We're already in edit mode, I believe. Yeah. So now I can go back and make those changes that I wanted to move to do up, bring in progress here. I could move done down. Let's delete all these transitions. All right, so now I'm going to add a transition from to do to in progress. And I'll call that start Dev now from in progress. Um, I want to have a code review option now before I do that, though. Ah, just one thing to note over here is that I can click on in progress and I can click edit, and I can change the name of in progress. But keep in mind that this in progress status is being used by other work flows and other projects. And that's what Gerald warns over here that this status is used in other work flows, editing it will affect them. So by changing the name overhearing description and things like that, I'm actually modifying the status elsewhere so I could name this to in development. But all the other projects that have in progress will also change in development, and it may not apply to those projects. So always be careful about changing the existing status is that you have. If you want to have a status to call in development instead of in progress, then you're better off just creating a new status and then adding that in here and then removing in progress. So coming back to the new status I want to add, I want to add a code review status. So if I look at these statuses that Jiro has available, um, so there is nothing like that. So I need to create one for myself. So let's call that port of you and you can basically just type out a new status, and it will tell you that this is a new status Click on it. I'm not going to allow old statuses to transition to this one quick ad, and it gives me a create new status dialogue box. And this is the same thing that you can do by going to the statuses section of Jerrod, the administrative section and you can create status is like this, so we'll call it code review. You can add a description of you want, and then you have to specify the category. Now. It's not to do kind of status, because, technically, the work's already started. The developments been done. Now it needs to go into the code review, usually done by the lead developer. So it's not start it has started, but it hasn't completed, so it's in progress, So we'll do that. So it will appear as a yellow box, and I'm going to bring that below in progress and then transition from in progress to code review. And let's call that Dev complete, Done now from code review. So now say that the code review is done, so the lead developer will now send it to the Q A team. So ideally, there should be a status for that, and we'll call it ready for testing. So the Q A team knows that. Ah, it's ready for testing, and once again it's an in progress category and Let's bring that to after code review and transition from here, and we can call it the same thing. Ready for testing transition. Now, once that's added the Q, A team can look at it and they can bring it into the in testing status so that everyone knows that it is actually being tested by the Q A team. So I'll create another status, and again, this is going to be in progress. It create and bring that down here in transition. And we can call this testing started, for example, or you can just call it in testing. But that's OK, and then we can bring done down and then transition from in testing to the last step, and we'll call this done. You could call the testing complete, but for now, we'll just keep things simple. And there you go. So we have created the workflow. Now you can only transition uh, basically sequentially starting from to do all the way to done Now, you might want to have transitions going backwards as well. So, for example, the Q A team's testing it, but they noticed, ah, that the ticket needs to go back into development because something wasn't implemented, so you can have a transition going back to in progress. Eso We can give it a name and we can add a new transition or weaken reuse a transition that's already going into that status. And in this case now there's only one transition going in, which is starting development. We're not really starting development because we're basically just moving things back and continuing development. So we'll create anyone and we'll call it back to death and hit. Add now. Similarly, if it is in code review and the lead developer notices that something is wrong, can also move back to in progress. And in this case we can reuse the back to Deb transition and hit ad. So that adds that back in a swell and you can go in and you can modify them more. You can add more transitions between these statuses. Um, but I think we'll just leave things the way it is right now. So there you go. We just modified this workflow, and I think the next step no is going to be to switch the project back to using this workflow instead of the copy that we made so for that will go back into workflow schemes and you don't need to hit save here cause it automatically saves. And so now we look at this workflow and we'll hit, edit, and the spike ticket or issue type is still using the its own workflow. So here we need to go back and we need to add existing were cool. And we'll look at, um this is the one that we just created, and we can make sure that it has our changes and yet it looks like it does it next again. We'll do all on assigned issue types. And in that window, you could see that the, um I think I I already lost it. But it showed you that the spike issue type had a workflow. So all on a sign was everything else and it replaced the copies. So it's back to using the live one. And if I go ahead and publish and associate, so go ahead and make its changes acknowledge. And so now, if I go back to work flows, I'll see that the copy is no longer there and we're back to using the the one that we created, the main one that we wanted to use, and you can see that now It has six steps. So if we view it, there you go. This is the new workflow that you created. So now let's go back to the issue Navigator, and we'll click on the story type, which is what will use a new workflow. And if we select you workflow, There you go. Now it's using this new issue type, and you can see that this from done, you can really go anywhere else. So hence there are no transition steps. But let me see if I can find a bug that's to do so now you can see that the next step would be to start Dev. When I click on Start, Devitt goes to in progress. Then I can specify Deaf complete. So now it's gonna go into code review and from code review. If you remember the workflow, I have two options. I can either go ready for testing or I can go back to death. And there you go. So ready for testing or back to death. So that's how you would edit a workflow, and you can pretty much customize it any which way you want. It's It's a very cool feature about Vera, and it allows you to customize how your team works on any given project. It basically is governed by this workflow as it can walk, Uh, or it determines how an issue I can walk through from start all the way till completion. Now we've modified this workflow for an agile based scrum project, So we need to also make sure that we update the agile board accordingly so that the new statuses get reflected on the columns appropriately. So let's take a look at that in the next video. 40. Updating the agile board with new workflow changes: now that we've created our new workflow and modified an existing workflow, let's go ahead and make sure that our agile aboard is updated accordingly. So we're going to go into the pep board. Just give it a moment to load here and you'll see that. So I'm in the Sprint view and we've got three columns as we had before. So let's go into configuring the board. And hopefully by now you're fairly familiar with how to configure the board and how to modify the columns. Just reminder that the columns, um, aren't exactly the same thing as the status, but basically you can map the status to the column. So it tells you what issues will show up in each of these Count Column. So, as in, um, issue with the status of in progress, will show up in the in progress. Call them now. If you look over here, you can see that there are a few on map statuses, and these are these statuses that we just created when we modified the workflow. So now it's up to us to bring these statuses in to these columns. Now I could move code review into an existing column, but I think it's probably best. And also just a quick note that year tells you that. Ah, these statuses have no issues. But this code of you does have one issue under that status. So let's go ahead and add some columns here. So I'm going to call this the code review column, and then we'll add another one, basically representing each status. Now this is only optional. Obviously, you can have multiple statuses within one column, but just to have things more easy to visualize, uh, going to map each status into its respective column. So now if I go back to the board, you will see five columns here. And this is the issue that we have just updated in the last video, and you can see here that I can click and drag to, either ready for testing or in progress. So it's no longer the case that I can transition into any other column or any other status . It only lets me do it based on the workflow that we have configured. And so let's go back to the board settings, for example, and let's modify and just take a look at what it would look like if we had two issues within a particular call him. So maybe, instead of in progress will call this in development and in development means that it's either in progress or it's in court review, because we don't really need to see it as a different column altogether. Being in code review kind of means that it's in the development team, and it's not really ready for testing so we can put them together here and let's go back to the board. So now we should see only four columns, and this ticket is back into the in development. So, Aiken, drag this into ready for testing. Now, ready for testing can go into in testing based on the workflow. Now from in testing. Aiken, bring it back to in development. If you remember the, uh, let me see if I can view the workflow here so in testing can either go to done or it can go back to death back into in progress. Now, what I want to show you is what if we could also transition back from in testing into code review? So let me actually go ahead and modify the were close so I can show you what I'm trying to do. But here you can see that I can move it to done, and I can move it to in progress. So let me go back to the workflow just for a second, and I'm going to edit this one, and I'm going to add a transition from in testing back into code of you. And let's just called us back to review and click add and then we need to publish the draft . Eso this. I guess we haven't really. Or perhaps we did. No, we did not have to go through this because when we were editing the workflow, we were doing it while it was inactive. So now, in this case, here's an example of something that you can do while the workflow is active. So I'm able to add a transition. It doesn't really affect anything. I'm just taking a status that already exists and transitioning to another status that already exists and adding a name. So gear allows you to do a change like that toe alive workflow because it's not really that impactful of a change. So now if I can go ahead and make a change to a live workflow. And as I mentioned before, the gear creates a draft of the workflow. So I'm not modifying the actual live version off the workflow. So in order for me to save this change, I need to go in and click on published draft. So what that prompts me with is a request in case I want to back up the previous version of the workflow and you can select a back up and you can select the name of the backup. You could do this. Maybe if you're not fully comfortable or certain about the changes you're making and feel that you might need to roll back to the previous version. So then it makes sense to save a backup copy and you can publish it. But in this case, I'm just going to select no backup and hit publish. And so now it makes the draft workflow the now live workflow and you can see that there is a transition. So if I go back to the board, I wonder if, uh updates. No, it doesn't. So let me click a refresh. And now if I click and drag, you can see that I can move it back to review or back to death. So before it would only let me dragon into the column as one single status, which was in progress. But now I can move it to review or back to death. So that's a cool thing. So I'm just gonna move this back to development over here. So now you'll see that the status is in progress. Now from here. Something interesting. Notice that I can't go anywhere. And why is that? So if I look at the view workflow, you can see that from in progress. I can only go to code review. But code review is part of the same column, so hence I can move anywhere. So in order to fix that, you can either have a transition going from code review, skipping or sorry from in progress, skipping code review and going to ready for testing, which will allow you to drag it into the ready for testing column. Or you could just go back to the board settings and you can bring the code review status back to its own column, which I think I would prefer to do so. Then you can go ahead and drag it in there. So there you go. Um, that should hopefully give you a refresher on the agile aboard configuration and how you can modify columns and, ah, now that we created that new workflow and we edited the workflow we have updated are agile aboard to reflect the new statuses. But just before we move on to the next video, I wanted to show you one more thing. Remember that we created a new issue type for this project, which was a spike issue type, and it had its own workflow, which we created as any workflow. So let's take a look at how that issue type would progress through this board. So if I go back to my backlog, there should be a spike test bike ticket. That's right here. So I'm gonna move this into the sprint, and it's gonna warm me that I'm affecting the scope. But I'm OK with that. Let's hit. Confirm. So now this bike ticket should show up in the to do column and there you go. So we'll take a look at the workflow and you can see that we only have three status is for this issue type to do in progress done, and we have mapped these statuses to the columns. So for this particular ticket, you'll see that I can only go from to do to in development. And it's highlighting Onley. Yeah, the entire column. So when I move it to here, it's going to change the status to in progress. And then from here, I'm just going to skip all the other ones. It's not gonna let me add anything to these columns because it doesn't have a status that maps to these columns, but it does have a done status, which maps all way to the end. So that's all I'm able to do, and so I can market is done, and then it shows up here now if this bike ticket if the workflow had statuses that weren't already being used in the other workflow as part of the project, it say it had some new statuses than what would happen is for the board settings. When you go to the column section, it will give you those statuses here is unmapped, and then you can drag and drop the statuses to whichever call him you wanted to show up under. So that's how you would go about that. Now let's move on to our next video 41. Understanding Workflow transitions: the last thing I want to talk about around work flows is just looking at screens again and how you can display a screen during a transition as well as some of the other things that you can do during a transition. So let's look again at the, uh, the workflow that we've created for our project. The permission example project. So if I go ahead and click on view now, I actually, you know what? I would rather work with the workflow that we created for the spike issue type. So let's go and view that one. And so now if I try to click on the transition, nothing happens because I need to be in edit mode. So again it's going to create a draft of the workflow. Now, when I select the done transition, for example, I can go ahead and I can click on edit and on this edit page or pop up, I can specify a screen that I want to appear when that transition takes place. So let's actually go ahead and let's select the scrum spike screen just as an example. So whenever ah, whenever this issue goes from in progress to done it's going to display this spike screen. So let's hit save, and we're going to need to publish that draft and I won't make any backup hit publish. So now that's live. So let me open up the issue. Navigator in another tab once again. Actually, we may be better off going to the board if we have any spike ticket that we can work with. No. So that's already done. So it looks like we may need to look in our backlog. There's no spike tickets. So let's create one and we can select Spike and let's create and call it another spike issue hit, Enter and oh, it's asking me So remember how we had set the description to mandatory. So there you go. Um, it's asking me to fill in a description so it didn't let me just created quickly, and I'll call this a Investigations might take it, and hopefully that should work. All right, so now it's created, and we can either go into the issue itself or we can move it into the sprint and then dragged the ticket around updating The status is so let's go ahead and start spike. No. When I click on Done, I should expect to see the speed. And there you go. So this is the issue. The spike issues screen, and you can see that it's got all the fields and you can go in and you can put put in your resolves. Um, so these are the results as an example. Now you could technically create a completely new screen and put nothing but the's spike results. Field on there, and you can make thes spike results field mandatory so that when the screen pops up, the user has to put in something cause rainouts on mandatory Aiken. Just remove this and I can hit done, But you can make it mandatory, and, ah forced the user to put in some kind of results and then hit done. And only then would the ticket be marked has done so. That's an example of how you can display screens during transitions. What are some of the other things that you can do? So let me click on edit again, and if I select this, you can see a bunch of other things over here, and I would say the most important things are conditions and post functions properties triggers their more technical in nature, and you can read up about them if you want. But let's just take a look at conditions. So conditions basically represent a condition that needs to be satisfied in order to make that transition. And JIA gives you a few options here. So, for example, this is a condition toe only. Allow the assigning to execute a transition. I think one that would be fairly common to use is this. One user is in project rule, so condition toe only allow users in a given project rule to execute a transition. So where I can see this applying this, for example, say you've got a project rule for your cue a team. And so you may create a condition that Onley the Q A team or anyone in the Q A project rule would be able to transition a ticket to being done, because obviously you want to make sure it's tested so you can give anyone else access or permission to market ticket has done unless it's been looked at by Q A. So you Onley give that permission. Ah are privileged to Q way to be able to mark a ticket as complete. So this is an example where you can go ahead and add conditions. Let me just go back and let's look at post functions. So this is basically something that you can trigger toe happen once the tick. Once the transition is complete so you can go here and you can add a post function, and it gives you a few options here so you can assign the issue to the reporter. You can send a notification to hip Chad if you've got hip chat integrated, or you can just update an issue field. So let's select that, and at that as an example, and so it gives you a few issue feels that you can pick from. So perhaps you may want to update. One of these feels like the assigning. You may want to make the assign E blank so it becomes unassigned once the ticket is marked is done, or you may want to update the resolution. So one thing to note about resolutions is that injera an issue is either open or closed based on the value of the resolution, so it's not really related to the status. You can have a status of done. But until the resolution is done, according to Jura, the ticket is still open. So I think it is good practice to mark the resolution as done every time a ticket is marked . Ah, as you know, being a complete or done status within your workflow. So let me go ahead and do that. And the the way the Jura identifies open versus closed issues is that the closed issues, they strike it off, they strike off the issue key, and we'll take a look at that. So I added the resolution as a post function for the spike issue type workflow. And so let's published draft and I'm not going to take a back up. Let's publish that and let's go back to the board where will probably need to create another test spike ticket. So let's actually go ahead and do that here another's bike ticket to test solution. And let's provide this and create need a description and let's ah, it's up here. So we're going to bring this. Let's do it this time through the agile board, so I'll confirm and go to the board. Actually, I could just click on here active sprints and there's a ticket. So first we move it to in progress, and now you see that there's the pep 27 is the issue key when I move this to being done so as we had configured before it problems for the screen so I can go in and put in a comment for these bike results had done. And here's the ticket and you can see that it has crossed off the issue key, which, basically, according to Ajira, means that this issue is now closed. So we have taken a look at a lot of things here in work flows, especially so we've created a new workflow. We've updated and existing workflow added new statuses, and we've mapped those statuses to an agile aboard to the columns in an agile board. And we've also looked at the workload, transitions and things that you can do during the transition. Before that, we created issue types. We created a new issue type. We mapped it to a project through a scheme. We then created a screen. We specified what screens will appear for different operations, and then we mapped them to the issue type by the issue type screen scheme and then finally we created fields, custom feels, and we looked at how you can make feels mandatory based on the field configuration and feel configuration schemes. So that brings us to the end of the Jiro Schemes, part of the administration section. 42. Working with Project Components: before I move on to the other administrative functions. I just wanted to take a few minutes and talk about project components. I know I had kind of mentioned it here and there, but we never went into it in any detail. And I wanted to just make sure we do that, because it is something that Jiro offers in a way that you can categorize your projects. So let's go through that. Let's use the permission example project that we've created and you confined components over here, and basically every project starts up with without any components. So the example that I had mentioned earlier in the course was say, for example, you had your team or a project was broken into back and development as well as front environment, so you can create components for each and then label your issues accordingly. And so let's just do that. So I'm going to create a back end component and will leave the lead empty for now. What I want to show you is this default assigning option. So you have a few options to make any issue that gets created, uh, to assign to a default assigning. So what that means is, if I create an issue with the component being back end, then it will automatically assign that issue to whoever I set as the default assigning. So here you've got four options. The first option is to have the component lead automatically get assigned, and that is specified here. So, for example, if I were to say that the KS developer user is the component lead because this user is my back end lead developer. So I would want all issues created to be assigned to that person. And then that person can then delegate it to, you know, other developers within his back and team. So I can go in here, and I can specify that the component lead who is that developer will be the default assigning for back and components. The other options are Aiken select either the project default, assigning or the project lead. So or I could leave it on a signed Ah, and where do you see the project default and the the project lead that you can see under users and rules. So I'm just going to open that up in a new tab and at the top over here you can see that the project lead is the administrator user. And this was actually set when I was creating the project because I was logged in as this. Ah, this user, um So it automatically put that user account into the project lead and you could modify that and you could change it to someone else. So you can still do that if you click on edit defaults over here, you can pick someone else to be the project lead. And you can also specify if the project lead is going to be the default assigning of any issue created within the project or if you just leave it unassigned so you can kind of put those settings in in the user Users and Rules Page. So now, going back to the component section. So I'll leave this, as is of pick this developer. And I'm saying that it will be the component lead, uh, for this back in project or back in component. And now let me create a front end component, and here I'm going to let's just use the project lead. So the administrator account and I'll hit odd. So now that these two components are created, uh, let's try and create some issues and see how they get assigned automatically. So I'll just go back to my backlog here and let me select create issues. All right, so we have this. Ah, this project selected If I go ahead and pick another project, you'll see that there are no components configured for dear course. So hands, I'm not able to select anything. Ah, the project that we did configure the components for is the permission example project. So if I select that, I am now able to select a component So let me call this back and issue and let me pick back and component, and you'll see that down here in the assigning feel it's set to automatic, which is what we want to leave it, because it will apply the automatic rules that have been configured for the project to assign this issue. So, for instance, if we did not have any components created, um, and this automatic setting would basically use the default assigning off the project, in which case it was left to being unassigned. So this issue, if you created it, it would just be on assigned not assigned to anybody. But now that we've created a component and specified a default assigning for the component for the back and component when I create this issue and we'll take a look at that so that should be at the bottom here. Yes. So this back end issue you'll see is assigned to the sorry right here. The assigning is the developer user. That was the default. So now let me go ahead and create another one, and the same will call it the front and issue. And I'm going to specify the front end component. And once again, a sign is automatic and we can hit Create. Now we expect this to be assigned to the administrator user. And there you go. That's how it works. And obviously, you can update this board to display the component over here. Aziz, one of those fields. Just so you know, it's easier to identify which issues are part of the back end and which issues are part of the front end. In fact, we can just go ahead and quickly do that. If we go to board settings and we go to the I believe it is card layout. Yep, and we'll just select component in the backlog view and we can hit ad and you can do the same thing for the sprint view and hit ad. And then when we go back to the board now, it's telling you that this is a back in and this is a front and issue, so that is how you can play around and use or take advantage of components in Jura. 43. Other Jira Administration and summary: before we can wrap up the administration section, let's just take a look at some of the other features that we never looked at. Now we're not going to be able to cover all of them, as many of them are very technical in nature. And some of them I haven't really seen being used in, um in the real world very often. So probably not that important. But if you find yourself in a situation where you want to use it, there's a lot of documentation out there on Jura and specific to that particular feature. So starting off here in the applications tab, the application access, which I think you should be familiar with, takes us to the site administration page, where you can configure access to the application. So we have covered that the jury software configuration has only one feature, really, and that is to enable parallel sprints. And I think this is something that's quite useful, and I usually always have it enabled and where you can use this is S O. For example, if you create a scrum board and you have multiple projects in this board and you have multiple teams working on the projects than its beneficial, and you might find yourself having to create multiple sprints. So that feature allows you to start and manage multiple sprints at the same time. So you can see here that I can actually start this while another sprint is already ongoing . So I find it useful. And that's where you can configure and enable that Juris Software Labs is something where, at last seaon can give you sneak previews of features that they're looking to release and future leases. So in this case, as off making this video, they have a burn up chart available. So if I enable that I can now use it and kind of test it out, Um, so I think I would have to go to the reporting section, and one of the charts that I can generate would be a burn up chart, and I can take a look at what it does and start playing around with it. Then, if you have other applications that are integrated into Jerious, such as hip Chatichai, this is where you would go in and you would be able to connect into them. And lastly, the application navigator is just a list of your applications, which right now is only jeer. So let's move on to the projects configuration top. And we've already talked about project categories if we go into one of these projects, so I'll open up that up in a new tab as well. You can look at the summary of how that projects configured. Um, you can look at the issue types and you can see here in our project thes bike is there. You can look at the work flows that's being used in this case to work flows and similar thing for screens. So on and so forth you can look at the fields now. One thing to keep in mind is that if I go ahead and if I click on edit for any one of these things, whether it's screen or work flows issue types, it's going to redirect me back to the jeer a administration page, because that's where you actually configure them. So here it's showing that, yeah, I'm using this bug screen. But if I want to edit it so opening that up in a new tab, it will take me back to the screen scheme. In the administration section so just something to be aware of every time you try to edit something and you are redirected out of the Project Settings Page so you can look at your versions, components, the users roles and permissions we've already taken a look at and you can do more configuration, such as issues security, which we never looked at. And this is one of the things I I don't see very common, but it basically allows you to control who can and cannot view issues. If that's something you're looking to do so on and so forth you can configure notifications for the project, uh, fairly straightforward stuff. So I'll go out of their and I'll go now to the issues tab, and we spend a good time a good deal of time on this page, and we went through issue types, workflow screens and feels Let's talk about time tracking for a moment here. So this is where you can configure things related to time tracking and an example is your working hours per day. So where does this really get used? Let's take a look at that. So if I go back to my agile board so this being a sample. We had already modified the board settings to use time as an estimate instead of story points. So now if I go in to this ticket and I estimate eight h, which basically means eight hours and check that off, it automatically converts it toe one day because Jura has eight hours within one day. So we don't want to configure issues that have, you know, 20 hours or you know so on and so forth. It's much you're better off seeing that in the form of days. So if I went in and I put in 20 h here, it's going to convert that to two days in four hours. And similarly, you can also change the default unit for time tracking. So in this case, it's minute. So if I didn't go in and put H at the end of ate, it would treat that as minutes and it would put eight m so it would only take me, uh, eight minutes to do this. So, technically, if I went ahead and did 60 m, it'll convert that to one hour, so on and so forth, so you can do some time tracking modifications here. You can also configure different ways that you can link issues. So I believe we saw this. We looked at how a ticket can block another issue, or an issue can be blocked by an issue. So you can go in here and you can configure different ways that tickets or issues can link to each other. We took a look at statuses. We didn't really go into this page. But we did create new statuses and you can see them down here. So this is another place that you can add statuses. You can also add resolution resolutions here. And we mentioned this briefly of how the retreats issues as either open or closed based on the resolution so you can go in and you can configure that now. One thing I want to point out is a lot of these pages have this little question mark over here beside the section. So if you click on that and I'll open that up in a new tab as well, it will take you to the help page specific to that page that you were on in here So you can go and you can read up about the resolution, feel value so on and so forth, and then go from there to the help tree and look at the other pages of help that they have . So you could go in and configure resolutions as well as priorities, which is a default field injera. You can set a new priority level. You can configure the color scheme so on and so forth the issue security schemes and notifications schemes we didn't really touch on because again, it's not something that I I see as being used very commonly. And again, this is where you can set who can or cannot view issues. The notification scheme is basically what determines how notifications air sent to users. So there's only one notification scheme here injera, and you can see that. Okay, if an issue is created, it will send a notification. All the watchers of the issue the reporter and the current assigning. So obviously you can come in here and you can make modifications to the scheme, or you can probably create your own scheme and use them in a specific project. And then lastly, this is definitely something. We looked at the permission scheme, which is where the groups of permissions are configured and assigned specific to projects. All right, so we talked about add ons and how you concert for add ons on there. And then that brings us to the system tab. The audit log is something that's interesting. It basically gives you a log of all changes that have happened. Injera, Um, all time stamped as well. So in case you're looking for, like, you accidentally made a change and you don't really remember what you did, you can come in here and look at what you actually changed. We have talked about roles and global permissions issue collectors is something that you know. You can gather feedback from any website and create issues through them. It's something that I haven't really played around with, but I believe it will generate some JavaScript for you to embed in your website something cool. If if you want to get that far into using Jura, you can modify the interface, the look and feel the system dashboard. You can take a backup of Jura so you can create a backup for cloud or for server here. Or you can import Ajira back up into here. You can configure your mail settings, the permission in notification helpers that something interesting that you can use as well . So you can type in a user, select an issue, and then select one of these permissions which, if you recall these air, the list of permissions that you would see in a permission scheme so you can select a permission. And you will tell you if the user has that permission for the specific issue. Or maybe these air doesn't. And Gereb would tell you what you would need to do to give that user the permission. Same thing with the notification helper, in case you want to see if you know notifications air going out for any particular thing. This the shared items, is where you can look at the shared filters and dashboards that have been created with angina. Um, and then some advanced options here won't look at all of them. But indexing, for example, is where you would go in and perform a re index. Um, and if you remember, we were getting the pop ups Every time he added a custom field, it would ask us to re index. So if you went ahead and did that, it would take you to this page and perform that re indexing. You can also modify your attachment settings. So if you have a size restriction, for example, so on and so forth. So there are, ah, the system configuration items. And then now, if you remember by clicking here, it's going to take me out of this administration page and take me to Site Administration, where we configured users groups gave them access. And then, if you want to keep going through here, there is a bunch of things around it. Last year in your general account, your billing details, someone and so forth, all of which are fairly straightforward. So that brings us to the end of the administration section. We've covered a lot of items and a lot of content, especially in this section, and hopefully by now you're a lot more familiar and comfortable with administering Jura and making changes and configuring work flows. In fact, you should be able to take a completely brand new instance of Ghira and start all the way from configuring users and groups and creating projects. The project rolls, assigning permissions and then going into configuring the issue types, screens and you know, in particular were close. I think that is probably the most configured item is the work flows. As you know, every team works differently based on the work flows, so hopefully you should be a lot more comfortable and familiar. And basically a gear grew. Obviously, practice makes perfect. So all the content that have gone through make sure you go in and you try out some of the ideas that you might have some of the things that you might want to do and go about it by using these videos as a reference but just practicing and making sure that you're more and more familiar with all the administrative functions.