Subscribe and click the bell icon to turn on notifications. In this video, we'll take a couple minutes to understand exactly what Jira is and what it's used for. Simply put, Jira is a project management and issue tracking tool.
As a fun little fact, the name Jira actually comes from Gojira, the Japanese name for Godzilla. Now, there are a lot of different ways that companies organize their projects. Waterfall, Six Sigma, Prince 2, and so on. Some of these methodologies or ways of organizing and getting work done are similar to each other.
Some of them are quite different from each other. Overall, the methodology that a company uses to... organize and get work done can determine the tool that they use to organize all of that. When you're using Jira, it will assume that your team is using the Agile methodology.
Now, I've worked with teams who are using Jira and they're not using the Agile methodology. There are apps and plugins that you can get in order to have Jira organize things in a different way. But by default, without any extended capabilities, Jira itself is...
Agile tool. This course is not really designed to be a deep dive into Agile methodology, but there are a lot of Agile terms and concepts that we'll come across inside of Jira. So that's why it's important to take the time to understand some of those core Agile terms and concepts. Now if you're already familiar with Agile, then great!
You can skip over the next few videos, but if you're new to Agile... or if you just want a quick refresher, then I'll see you in our next video where we'll get a crash course on the basics of Agile methodology. In this video, we'll get an overview of Agile methodology. Now, before we begin, I want to point out that this is not going to be an in-depth look at Agile.
There are tons of great courses and workshops out there that do. take a deep dive into Agile methodology. But if we were to try to do that in this course, there wouldn't be any time left over for Jira.
As we learned in an earlier video though, before we can understand how Jira works, there are some things about how Agile works that we need to understand first because Jira just assumes that we already know them. So that's the purpose of this video, to give a crash course on Agile in a single video. For our purposes today, the term... agile refers to a methodology that software development teams around the world use to get stuff done.
It's a methodology that promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. Now, Jira certainly is not the only agile tool out there. There's quite a few of them.
In fact, I've worked with teams that prefer to use a simple whiteboard on the wall in the office with something like post-it notes instead of using a digital tool at all. But of course, physical whiteboards won't work for everyone. There is no right or wrong tool when it comes to Agile.
It's more about what's right for your team or your organization. With that in mind, Jira is something that some of the world's largest companies and organizations are using for their Agile workflows because for a lot of teams, It is a lot easier to see things using a digital tool like Jira. To organize our work using Agile methodology, one of the most important tools that we'll use is an Agile board. And that begs the question, what is an Agile board? On an Agile board, we'll have different columns.
In Agile, sometimes they're called lanes. In Jira, they're called columns. Think of these as the steps you need to get a project done.
In the simplest project, there's going to be at least three columns to do or not started. So the project hasn't even been started yet. In progress, it's currently being worked on and done. It's complete.
Of course, boards can get even more complex than that. In Injira, you can customize it to add in whatever sort of columns that you want, but this is just a simple example of an Agile board. Now, underneath Agile, there are two primary ways to organize projects.
They're different workflows for how your team tackles those projects and the process that they use to get them done. One is called Scrum and the other is Kanban. The differences between these could be an entire course in and of itself, but for our purposes today, there's really one key difference.
to keep in mind. And that difference has to do with something called a sprint. And again, that begs the question, you can start to see why some of these concepts that we're going to see inside of JIRA doesn't really explain them. So what is a sprint?
Well, a sprint is a predetermined amount of time where teams determine what work is going to get done in that time. This might be easier. Let's walk through an example of this just to explain.
So let's say our team has decided we're going to work with a two-week sprint. So that means every two weeks, our team is going to hold a sprint meeting. In that sprint meeting, it looks something like this.
Start by discussing the last sprint. A lot of teams that I work with, they prefer to go around each individual team member and go around and say, what went well for you in the last sprint? What didn't go well for you in the last sprint? Are there any roadblocks that you came across or things that we can try to work better?
This goes back to that iterative and continuous improvement. What can we do better in the next sprint? And then as a team, discuss and agree on the work.
And again, usually teams that I've worked with, they'll go around individually, each team member, discuss and agree the work that's going to be completed in the next sprint. What's the highest priority thing to do in the next two weeks? And then... day-to-day workflow will be taking those projects. So let's say these are the three things that I need to get done in the next sprint.
And again, if there's a priority level to these, then of course that will be something that will be discussed in the sprint meeting. If there's not, then it'll be up to me to determine which ones of these I need to get done. We just know that we need to get these three things done in the next two weeks. So the process for this is to take a single...
ticket and drag it all the way from left to right before you bring another one on. You don't want to have multiple things in progress if you can help it. You take one all the way over to completion until they're all done. Then after another two weeks, you're going to hold another sprint meeting. And in that sprint meeting, just like the last one, it's going to go around and say, what went well?
Were you able to get all the tickets across the board? If not, what sort of roadblocks did you come across that... kept you from being able to complete all of those things that we had said needed to get done?
What can we do better to make sure that we're able to hit those in the future? Or is there better communication between teams? And as a team leader, it's really helpful to hear some of these roadblocks that your team is having to be able to fix those so that more work can get done.
And then again, discuss and agree the works that are going to be completed in the next sprint and keep going. Now, with that said, not every team works best with these blocks of time for their project, with these sprints. Sometimes it might be better for your team to work on projects on an ongoing basis. And that is where Kanban comes into play.
So in a Kanban workflow, the board may look very similar, but the workflow is going to be different where you take your ticket and you drag it over. Again, you're still going to try to get that all the way to completion if you can. But as you're working on things...
new issues, new tickets may be added to the board at any given time. Because with Kanban, it's more of an ongoing thing. You're working on the projects on an ongoing basis. Okay, so to recap, we have the Agile methodology that's made up of two primary ways to organize and the process for getting our projects completed.
One is Scrum, which has a sprint where your team will sit down and figure out all the projects that your team needs to get done in that. predetermined amount of time. Then there's Kanban where there aren't sprints, but your team works on projects on an ongoing basis. And as I mentioned at the beginning of this video, there's a ton more depth that we could go into when it comes to Agile, but we're ready now to move on to some of the key Agile terms that we'll find inside of Jira.
And we'll learn more about those in our next video. In this video, we'll look at a couple of Agile terms that will come across a lot in Jira, stories and epics. So this is a screenshot of what it looks like when we create a new issue in Jira. And this screenshot right here is one of the most common reasons why I get this question from folks who are new to Jira.
Why does this say story? What this is referring to is a concept inside of Agile methodology called user stories. So a user story has a formula that goes something like this. As a blank type of user, I want blank some sort of goal so that blank some sort of reason. Here's an example.
As a web developer, I want to be able to add users to Jira so that my coworkers can report bugs. Or another example would be as a driver, I want my car's dashboard to be voice activated so that I can get directions safely while driving. Or as a cashier, I want to have the total calculated for me so that I can give the correct change back to the customer. These are just examples. Not all user stories have to be done exactly like that.
But you can see the wide variety here, kind of using that same formula. And generally speaking, user stories in Agile are how developers around the world break up their work. You'll notice that there's no technology mentioned. It's done this way specifically to leave all the technical stuff out of it.
That doesn't matter. The person driving the car here just wants to be able to get directions safely while they're driving. It doesn't... They don't care how you get the GPS to be voice activated.
They just want it to work. As a developer, figuring out the technical stuff to achieve that goal is your job. And that brings us to epics.
So probably the easiest way to think of epics is like a big, massive, well, epic-sized story. Not every story needs to live inside an epic. But if you have something, especially if you're using Scrum where you're working with sprints, like the example in our last video where we have a two-week sprint, if we're working on something that's going to take longer than two weeks to get done, then that's going to be an epic. And we want to break that down to smaller projects, essentially, into smaller user stories that can be tracked in the epic. So the hierarchy can look something like this, where you have multiple stories all linked.
to that epic. So here's an example. Let's say the epic is the core functionality for note-taking apps, say, that we're building.
Probably not going to be able to get that done in a single sprint. But here are a few stories that we may be able to get done in a single sprint. So we can work on one of those, and then the next sprint, we can work on another.
And we can start to see, as we track the epic, have those stories linked to it, being able to track the overall progress in the Epic is a really great way of being able to break down big projects, big Epic projects into smaller ones to get them done. Okay. So to recap, when you see stories in Jira, it's referring to user stories and Epics in Jira contain multiple user stories or other issue types as well, but we'll get to that.
later on in this course. Oh, and I should probably mention, if you're using Jira for more than your dev team, stories don't really have to be written out that way every time. Because Jira is created as a dev tool, stories are basically the default method of organizing your projects inside of Jira.
And I've worked with marketing teams and graphics teams that all use Jira software, and they just use stories as whatever project they need to get done in their sprints. But that... probably raises another question because user stories and epics sure sound a lot like the projects that you need to get done at work. And I've even mentioned that, you know, they're the projects that you need to get done. And they are, but Jira also has projects too.
So what are those? Because that's a different thing. That's exactly the sort of thing that can make Jira so confusing when you first jump into it. So now that we're familiar with what stories and epics are, Let's clarify some JIRA terminology by moving on to our next video, where we'll learn about some JIRA terms we need to know.
In this video, we'll look at a couple more terms we'll see in JIRA, issues and projects. Now, at first, these terms seem very straightforward. We all know what issues are, and we all know what projects are. But what does JIRA mean when it's using these terms? Because it might not be what you think.
Let's start with issues. Issues are the heart of what you'll be tracking in Jira. Issues are containers for fields, and fields hold all of your data. So things like the description, the summary, who it's assigned to, a due date, attachments, comments, all of those things are fields on issues. One of my favorite ways to explain issues is to think of them like post-it notes.
The note itself is really just an empty container. You can put... any sort of information that you want on it. You can even color coordinate your notes to help organize that information better. Just like inside of Jira, you can have different issue types.
Now you can also have custom issue types, but it does come with some pre-installed like stories and epics like we learned about in the last video. Maybe on the story issue type, you wanna have the summary, description, a due date. Maybe on the bug issue type, you also want to have the OS or the operating system, so it's easier to know where that bug took place, so it can be fixed easier.
All of this is customizable, of course. It kind of depends on what sort of data you need to track. But you can start to get a sense for what JIRA means when it's talking about issues and how you can have different fields on different issues.
And that brings us to projects. Now, as I mentioned earlier in this course, projects in JIRA probably aren't really what you think of when you think of a project. By that, what I mean is when you start a new project at work, that... That... does not necessarily mean you're going to start a new project in Jira to track it.
So let's go back to our example of the post-it notes here. We have these different projects. All of the issues in the top row are in the web dev project. All of the issues in the middle row are in the marketing project. All of the issues in the bottom row are in the customer service project.
Those issues actually live inside of the project. And in the project settings... is where you can tell Jira what types of issues will live in there.
And of course, as we learned, the issues contain the data and contain different types of fields. So let's say in the WebDev project, we want to be able to have bugs so we can track those in there. But the marketing project doesn't need bugs, so we're going to hide that from them. We're not even going to show them bugs because they don't need to see that.
You can start to get a sense for how you can customize this to fit your organization's needs so they can see the information, they can track the information that they need, and anything else that just would end up being clutter and hinder productivity, they don't even need to see. Okay, so to recap, as we learned, issues... are things like stories, epics, bugs. Those are types of issues in Jira. And of course, you can create your own custom issue types as well if you don't want to, or if you want to add to the ones that are the built-in, pre-built ones that come with Jira.
And issues hold the fields that contain your data. Now, projects are where the issues live inside of Jira. And you're not necessarily going to be... creating a bunch of projects all the time. Okay, so now that we have a good understanding of some key concepts, let's actually hop into Jira.
So we'll do that in the next video. In this video, we'll start getting familiar with Jira by looking at its interface. Now, when you first log in, by default, Jira will send you to this area called Your Work. Right now, you can see there's... not really a lot here because we haven't done a lot of work in JIRA yet.
But as we continue throughout this course, we'll see things like the recent projects that we visit will show up here, items that we've worked on, issues that we've worked on, issues that we viewed or things that we viewed here, issues that are assigned to us, or any items that we've starred or favorited, bookmarked, same sort of concept. But for now, let's get an understanding of what we're looking at here and start by moving from the top, up at the top. left hand side.
So this is the app switcher and in here we can switch between the different Atlassian products that we have. So you can see if we had Confluence which is Atlassian's wiki tool for documentation, knowledge base, things like that. If we had that then we would see that actually right here or we could start a trial if we wanted to. Of course the key thing to keep in mind here is starting the trial or actually subscribing to this since I'm using Jira software on cloud, that would be another subscription. So in order to do that, we would actually have to have administrative permissions, which means access to the billing information as well to be able to set that up.
Or down here at the bottom, we can actually, if we have, again, if we have administrative permissions, we can customize this. So you may see some different things, just adding in different links. worked with teams that add links to a different intranet or specific documentation, website, things like that.
Just a quick way to link that and being able to see that up here very, very quickly directly inside of Jira. Next to that, we have the Jira logo here. Depending on your organization, this may be your company's logo.
The Jira administrator has the ability to customize this. But by default, when you click on this, it's going to take you right back to your work. where we were when we first logged in. So at any point, if you get lost in Jira, you can click on the logo up here and that will take you back home.
After that, again, we have your work, but here we have quick access in the menu to some of the things that we would see on this page. But as we're working in Jira, sometimes it's faster to not have to navigate to this page fully. So we can see the recent things that we viewed. You can see some recent dashboards or filters that we viewed.
We can go to the Your Work page. It's probably faster just to click on the link up here, as well as being able to see recent boards that we've looked at. And don't worry, we're going to look at Agile boards and these boards later on. Just know that this is where you can access a lot of the recent things that you've looked at.
Then moving along, a lot of these just start to make sense as we're going through this course, because we're looking at what the projects and filters and dashboards are. I know we got a sense for the concept of projects previously, but we'll actually see them working inside of Jira. So it'll start to make more sense. But for now, just know that this is where you're going to access all of those things. So you can see I have a project that I've starred here, and actually we can come in, and if we remove it from the star, then we'll see.
this update. Let me go ahead and refresh. And we can see it's no longer starred. It's recent. So as we view more projects, this one will eventually get kicked off this list in the menu.
Or we could come in and we can star that to make sure that it is always there in this menu. As well as, of course, as you can imagine, finding it under all of our starred items on the Your Work page. Next to the projects, we have filters.
Now, essentially, in a nutshell, filters are saved searches. And like projects, you can star your favorite filters if you want to, to make sure you can see them up here for quick access. You can view all the filters that you have, or you can start building a new one through advanced search. And again, we'll look at that in more depth later on in this course. Next to the filter, we have dashboards.
So a dashboard is... Essentially a quick way to access things that we're working on or build charts, things like that. But one of the big differences between this dashboard and the Your Work section is Your Work is just focused on you, the user that is currently logged in. A dashboard can be customized. You can add in different gadgets, different reports, different pie charts, things like that, and then share them.
across different users. Multiple teams can have the same dashboard so everybody sees the bugs as they come in, things like that, as opposed to everybody going to their own Your Work page, which is going to change as different users are seeing different things. So that's just one thing to keep in mind.
One thing I would like to point out with this is depending on your version of Jira, if you're using an older version of Jira, then the dashboards are the default place that you go to when you log in. The Your Work section is relatively new in the last year or so. Around 2020, I believe, is when they started to migrate over to the Your Work section being the default place where you log in.
Next to dashboards, we have people. So this is where you can find other people in your organization. You can start a team. We'll look at this later on in this course.
But it's just a place where... You can get a collection of people together to work on things and being able to see what other people are working on very quickly. And then, of course, we have the apps.
And I mentioned this in the last section, the Atlassian Marketplace, where there's a lot of functionality that you can add onto Jira. Throughout this course, I will not be using any of these apps or add-ons. This course is specifically designed that way, so I won't be using those extra third-party things. that you won't have access to without paying, but you can explore the marketplace and you can find new apps in here. Moving right along, we can click on the Create button to create an issue.
Don't worry, we'll be looking at this screen and we'll be using this quite a bit throughout this course. Just know that's where you can create an issue here. Then up at the top right-hand side, we have search, so searching for issues or boards or things.
in our Jira installation. We can search for those here. I do want to point out that we can get to the advanced search, which is where we can go to create our filters. So again, under filters, you can see the advanced easy shirts going to the same place. Just another way to get there.
Or we can see all of the issues in our Jira installation, all of our boards, projects, filters, or people. One thing I do want to point out here has to do with the permission levels. Going to all the issues, if you are a JIRA administrator, you're going to be able to see everything. If you're not a JIRA administrator, you're going to be able to see all of the issues you have access to.
So that might be a specific project, but you might have access to the web dev project, but not the marketing project, for example. That is going to be set up, those permissions are set up by your JIRA administrator. And then over here we have notifications. So this is pretty straightforward.
You'll start to see numbers pop up here when you have notifications, like when someone comments on an issue that you're watching or when someone tags your username somewhere in Jira. This is just a quick way to hop to wherever those notifications come from. You can see down here it's saying, hey, there's notifications in chat apps. You can connect your Jira installation to Slack or to Teams to get notifications in there. You can get notifications through email as well.
But then all of the notifications that you see in any of those other integrations, you'll also see here inside of Jira showing up at the top right-hand side here. And then we have help. This is pretty straightforward, but I do want to point it out because if at any point, as you're following along with this course, if something doesn't make sense, make use of this.
Atlassian has some super detailed and incredibly helpful documentation that can answer just about any question that you have. And not only for this version of Jira, but they have it for previous versions as well. So if you're using an older version of Jira server and you see something that I'm working on that is a newer feature that you don't have access to, then you can do a search for it and see if there's a workaround or if there's something else that you can do in there. And if the help documentation doesn't have what you're looking for, Atlassian's support team is amazing. Even though I am not associated with Atlassian at all, I've interacted with their support team a lot over the years and they've been really helpful to either fix a problem or even if it's just someone to bounce ideas off of for the best practices.
Say, hey this is what I want to do. What's the best way to set this up and organize this inside of Jira? So take advantage of the help if you ever get stuck.
And we have our settings. So if you are a user, you'll have limited options in here. You won't have access to things like your organization's billing details and all of that information, as well as adding users.
That's something that will increase the bill. So depending on your permission level, that will determine what you see in here. But at the very least, you'll see things like your personal settings. So you're managing your time zone, managing your email notifications that you get directly from JIRA, things like that, your profile information, stuff like that. And then of course, last but not least, we have our personal settings, same as pretty much coming in here, changing profile, things like that.
Pretty straightforward stuff as far as the personal settings are concerned. Okay, so that is a look at the user interface in Jira. I know I threw a ton at you there. And of course, as you've seen throughout this video, as we choose things from the top navigation, then And all of this area here is going to change to show whatever it is, wherever we're navigating to, as you would expect that primary work area changes. And we'll get familiar with all these different areas in Jira as we start to dig into things.
But for now, I would encourage you to take some time in between videos, click around in here and just start getting accustomed to where things are at and how the interface changes when you click around. And don't worry, you can always get back to this Your Work area by clicking on the logo up here. here. And that brings us to an end of this section. In the next section, we'll start by getting an understanding of the two types of projects inside of Jira, team-managed projects and company-managed projects.
See you there. Before we dive into learning about team-managed projects, we'll take a couple minutes in this video to learn what team-managed projects are and how they compare to the... other type of project in Jira, company-managed projects. So let's start with our team-managed projects.
Team-managed projects were introduced into Jira in 2018 as next-gen projects, and then they were renamed in 2021 to team-managed projects. The primary reason I want to point that out is because Jira's first release was in 2002. So team-managed projects coming in at... in 2018 is relatively new. So depending on what version of Jira you're using, you may or may not have access to these. Now, one of the key things about team managed projects is that they do not require any Jira administrative permissions to create them.
The reason for that is because all of the entities live inside the project. By entities, I mean things like the issue types. So any issue types that you create, inside of a team-managed project lives entirely inside that project.
By comparison, the other type of project, the company-managed projects, they used to be called classic projects and they were renamed in 2021 as well to... correlate with the team managed projects. A company managed project requires Jira administrative permissions to create.
One of the key reasons why Jira admin permissions are required for company managed project is because entities can be shared across other company managed projects. So those entities, things like issue types, and statuses, and resolutions. For example, if you create a custom issue type, in a company-managed project, any other company-managed project can use that. So you have to have JIRA admin permissions across all of those projects to be able to assign those issue types to those different projects. On the flip side, the team-managed project, if you create a custom issue type in a team-managed project, it only lives in that team-managed project.
No other team-managed project, no other company-managed project has access to that particular issue type. I mean, I suppose you could create another issue type. If you create an issue type called bug in one team managed project, you could create another issue type called bug in another team managed project. But from the back end, as far as JIRA is concerned, those are two different issue types. They just happen to both have the same name.
Okay, so to recap, team managed project have project scope entities. So things inside the team managed project entirely live. in that project.
For that reason, or because of that, there's no special permissions to create a team-managed project. When you create one, you become the administrator of that project, and everything that you create lives inside of that project. That makes them very fast and easy to set up and maintain because any team member in the organization can create one, and they can then maintain that project.
They can invite other users to it, and these... the team can work together. Company managed projects, on the other hand, because they have global entities that are shared across the entire organization, across the entire Jira installation, that means that requires that they have to be created and maintained by Jira admins. So for that reason, they can be more complicated to set up and maintain because these entities are shared across multiple company managed projects. And we'll be looking at the more complicated company managed projects and digging into those later on in this course.
But for now, let's move on to our next video where we'll learn how we can create a team managed project. In this video, we'll look at the process of creating a team managed project. Unfortunately, this process is very simple.
All we need to do is to come up to projects, create project. Now we can pick the project. template.
So this would go back to some of the concepts that we learned about in the last section. Is our team using a Kanban workflow, a Scrum workflow with sprints? If you're not familiar with these terms, we covered them in our previous section, just the concepts.
These are agile concepts. Or maybe we just want to bypass agile altogether and manage a list of issue types like tasks and bugs. Or over here on the left, there are a lot more project templates that we can pick from. I do want to point out. that depending on our version of Jira, we may not have access to all of these templates.
So let me show you what I mean. If I come into service management, and let's pick, let's say the IT management one here at the top, notice there is a lock on this template. That's letting us know we don't have access to this yet because I'm using Jira software for this course, and this template requires features that are in Jira service management. Now, if we have admin permissions with access to billing, because that is a different product with different billing, we would have to have access to that. We could unlock that now.
And the same goes for a lot of these templates. If we see this lock, basically it means our current JIRA license doesn't have the features that we need for that template. Now, there are some templates that we could use. Let's say, let's go into design and...
pick this one here for project management, you can see this is using Jira work management as a product, but we have access to this template. The reason for that is because I'm using Jira software and Jira software is basically Jira work management with the agile software development features built on top. So I have access to the Jira work management templates. But let's go back to software development.
I'm going to pick the Kanban template. And we can see what this template is doing for us. It's going to create some issue types for us.
The epic issue type, story, bug, task, subtask. It's going to give us a workflow here with the columns on our board. Pretty simple to do in progress and done. Let's go ahead and use this template.
Now the key thing to point out here is really this part right here. I want to mention this because when we create this project, if we create it as a team-managed project, we cannot switch that to a company-managed project later on. We have to create a whole new project to do that.
And the same is if we create a company-managed project, we cannot switch that to a team-managed project later on. So we have to know which one we want to do at the point of creating. So let's select our team managed project since that's what we're working with here today.
And let's give this a name. This will be our website 2.0. Give this a key. So this key is going to be on all of the issues.
So if we say this key is web. So all of the issues will be web dash one, web dash two. It'll just be a sequential order for all of the issues that get added into our project.
Then once we're happy with this, click on create. and our project gets created. All right. So now that we have our team managed project created, let's get familiar with how it is organized here in Jira.
And we'll do that in our next video. In our last video, we looked at creating a team managed project. In this video, we'll continue right along and look at how to navigate around that project. So right away, we can see by default, we're taken to our projects agile board. And this is a Kanban agile board based on the project template that we chose in the last video.
So the workflow for this is to take issues from left to right. So let's create a new issue here. Let's say this is our, let's just say build flowchart for website functionality. There we go. Once we have this created, we can see.
a few different things here. So one, we can see the project key. This is something, again, I pointed out in the last video when we created this project.
This is the first issue. So we can take this and we can left click and drag throughout the different columns, right? So that's the basic process that we're going to do.
Take the issue from left to right as work is completed. Now we can customize this. Let's say, you know what, we actually need a new column here for QA so we can track that.
So once we create this, you can see how the cursor changes to a hand. I can left click and drag the entire column to organize this. And you know what, before this is actually done, we need to run this through QA to make sure that this has been done. And then once that's done, you can actually pull that in. Now up here at the top, we can filter.
any of the issues. So if we wanted to filter those issues, say, just show the ones that have to do with the flow chart, you can see how it's highlighting that. Of course, we only have one issue on here, so it's pretty simplified.
But we also have the ability to see who is in this project and who really filter by that. So only see the issues that are assigned to me. Right?
So right now, none of the issues are assigned to me. Let's change this here. Select this. In the assignee right now it's unassigned.
Let's assign this to me. And now we can see this issue has been assigned to me. And we can start to filter those issues that based on who those issues are assigned to within the project.
Now we can take that to another level if we want by grouping them. So we could group by the assignee or by if there's subtasks. Let's see what this looks like.
You can see when we group this. It creates in Agile, this is called a swim lane. And so basically what this does is it gives another way of viewing and filtering out the issues. If you think, you know, we have a lot of different issues on this board, being able to group them is really, really nice way of doing that.
And see, OK, these are the issues that are unassigned, which maybe we need to assign that to somebody and make sure that that gets done. So work isn't slipping through the cracks. Of course, in this example.
We only have one issue and it's assigned to me. So we only see this one. But actually, you know what? Let's change that. Let's look at creating more issues and get a better look at that screen that we saw when...
we assigned that issue. So let's move on to our next video where we'll do that. In this video, we'll look at creating issues in team-managed projects.
So there's a couple of ways that we can create issues, including the one that we looked at in our last video here on the board. Just to clean this up, I'm gonna go ahead and switch this back so that we're not grouping it by the assignee. So we can come in and create an issue.
Let's say maybe this is our UX plan for web app, whatever our issue is. Hit enter on the keyboard and we have our issue created. Now, another way that we can create an issue is using the create button up here at the top or by using the keyboard shortcut C for create.
So when we hit the keyboard, make sure I'm not actually have that selected. There we go. Hit the keyboard shortcut C.
and we can see it's going to pop up this window where it can create an issue. Now, the key difference here, as we can see, is we have a lot more fields that we can fill out when we create the issue this way. So let's give this a title.
There we go. Now, this little red asterisk here, of course, means that this is a required field. The summary is kind of a special field in Jira.
So if you look... on the board here, you can see that's the summary. And so it's displayed in different places inside of JIRA that make the summary a required field really across all of the issue types.
We can add whatever we want to these fields. But I do want to point out this little checkbox down here. This is just a little tip from my experience.
It's saved a lot of time because as soon as I hit create, this window will close. But if we're creating... multiple issues, then sometimes it can be just time consuming to hit create and then it closes and then we have to open it back up again.
So if we check this little create another box, when I hit create, this window is going to stay open. So we can create another one, whatever we want our summary to be. And we could just continue doing that, continue creating those.
We can see. Our other issue has been created. I can uncheck this.
And now when I hit create, that window is going to close out and we can see those issues have been added to the board. Another little tip when creating issues, let me hit C to get back to this here, is if we don't need all of these fields, sometimes, especially again, if we're creating multiple issues, sometimes it can be annoying to see all of these fields and have to scroll up and down if we don't really need to. So we can configure the fields and customize this to only show the ones that we want. We want to show an attachment, show how it's flagged, if we want to add in labels. However we want to customize this, we can configure those fields that we see just to make it a little bit faster to fill this out and create our issues.
Now it is worth pointing out that we can customize this. add or remove fields from this list. And we'll look at that in our next video when we're configuring this project. But before we do that, there is one more thing I want to show.
So let's create this issue here, the design there, create that. So all of these issues here, we can see a difference between these issues and this one right here, who it's assigned to. So we can assign these two different users.
Even if we didn't fill these fields out when we first created it, if we create it on the board and it just creates the issue right away, like we saw for this one here, as soon as we click on the issue, it's going to open up this screen where we can see those fields and assign it to somebody else if we want to, assign it to Mary on our team. And then once we close out, we can see this is assigned to Mary, right? And this one's assigned to Dan. these are unassigned.
So again, if we go back and we can group these, we can start to see how all of this works together and how we can use these issues to really start to filter down to only what we need to see. So when Mary is working, maybe she only wants to see the issues that are assigned to her because those are the ones that she really needs to focus on so she can filter those out. Similar to what we looked at in our last video when we're getting familiar with the layout. Okay, great. So now that we've seen...
how we can create issues and gotten some tips and tricks there. We've gotten more familiar with the fields that are on the issue by default. Let's move on to our next video where we'll look at some of the ways that we can customize our team-managed projects. See you there.
In this video, we'll look at some of the ways that we can customize our team-managed projects. So let's start with issue types and how we can add in a new issue type. Before we do that, I'm going to hit C on the keyboard just so we can see.
Right now, we currently have two issue types in here. We have our task and our epic. So let me cancel out of this and let's add in a new issue type. So I'm going to project settings. issue types and then add in a new issue type over here.
You can see that Jira has a couple of them that are suggested that we can add. So we could either add one of these in, add that and now if we create a new issue, we'll see that there's a bug in here as well. Or what we can do is we can come in and create our own custom issue type. So maybe let's call this an idea. Let's change the icon to the light bulb here, create that.
And now we have our own custom issue type that we've created in our project. And you can see right here where we can customize the fields that are on that issue. So, Again, if I create this, we can see how it looks on the other end.
If I switch to a bug, let me show all the fields. I had that filtered. We can see the fields that we have on this issue type.
Now, if we switch this to our new custom one, we can see these fields, and we can customize these. Let's say on the idea, let's give this a due date. on actually, you know what, we could even come in here and say, let's give this a drop down.
Actually, let's do this on the bug. Let's do that on the bug. Save this on the bug.
We'll come in and do a drop down. And this is going to be location on sites and then fill in the options that we want in the drop down. So maybe it's in the header, the body. or the footer, right? Make sure to save the changes.
Now, if we create a new issue and we have this as a bug, we can see we have this dropdown that we've added. And this is just a really great way to be able to organize everything, to be able to say, you know what, the bug is actually in the footer on the site. And then we could start to fill this in and start to, you know, add in more descriptions to that. But. On the idea, we have a due date.
That field that we added in, we have that, and we don't have the location on the site field. So hopefully this starts to get kind of the gears turning in your head. You can start to see how the fields are on the issues, and like I mentioned in the last section, how the issues contain the fields that are going to contain your data, and you can come in and start to create custom fields add in some pre-built fields basically is what Jira has for some of those, like the due date. It's really just kind of a pre-built field that is a date field that's automatically created for us.
Okay. So now before we wrap this up, I want to kind of go over some of the rest of the settings that we can customize Team Managed Project. Customizing the issue types is probably going to be one of the more popular things that you're going to do.
That's why I wanted to focus on that. quite a bit, but let's go through some of these other settings that we have to customize our team managed projects. So head back to our project settings here. So in the details, these are some of the settings that we picked when we created the project.
We can change that here. Things like the name of the project, the issue key that you can see here, as well as choosing who the default assignee is going to be. So when we were creating those issues, they were assigned to nobody.
We could choose instead, you know what? I want it to be assigned to the project lead, which we can set right here. So if this was set to project lead, when I create a new issue, unless I assign it to somebody specifically, then it will be assigned to the project lead, in this case, Dan. And what that's going to do, what I've done in my experience with teams here is to set a point of contact on the team to have any issues created assigned to that person. So that person is kind of in charge of making sure that nothing slips through the cracks.
Anything they will then delegate to who it needs to go to, or if it's something that they need to do, then of course they can take it. take control of that as well. We have the settings for our board.
So in here we can come in and add in new columns that we looked at. We can reorganize the columns if we need to. We can customize our board however we want.
Now you'll notice we have the columns here, but we also have the statuses, right? So this is something that's kind of cool. I'm going to take this, let's add this here, and let's come in and delete this column.
So now we have two statuses on a single column. Watch what happens when we do this. I'm going to come back to the board here. Now, if I group this by nothing.
So, okay. So now if I come in here and I click and drag this, I can say, you know what? I can either take this to in progress or I can take this to QA. So those are statuses, right?
So if I click on this, you can see the current status of this particular issue. If I take this and drag it to QA, that takes that issue and drag and puts it in the QA status. So that's really what's going on behind the scenes. If we head back to the settings here, we can see that's really what's going on behind the scenes is we have the columns in the board. And then when we drag an issue from one column to another, it's changing the status of that issue.
Now, in my experience, there are a few different reasons why you might want to do something like this, but probably the most common that I've come across is the simple reason that some teams have a lot of different statuses for issues. And if every single one has its own column, then you might have to start scrolling left and right to see all of the columns that you have on your board. Putting multiple statuses into a single column can make it a lot easier to see everything at once. Okay, so let's go back to our project settings and look at some of these other settings that we have here. We have the access so we can control who can see our board or who can see basically our project.
So right now we can see anyone that has access to the entire Jira installation can access and administer this project. And depending on what plan we have, what license we have to Jira will allow us to unlock more control over who has access. to this project. Now we have the issue types. We looked at that already coming in here and customizing the issue types in this project.
We can control the notifications. So when somebody creates an issue right now, anybody who is watching that issue, who it is assigned to, or who has reported it, which in Jira, the reporter is the person that created the issue, the user that created that issue. Then we can come in here and customize this if we wanted to, to control who gets the notifications.
But by default, usually I found the defaults here work pretty well. And then we have the features. So we can come in here and turn on or off some of the features. So if we go back to our project, we can see we have a roadmap here.
And we'll look at roadmaps later on in this course, kind of what those are. But We can turn that on or off if we wanted to. So if we turn that off and come back and we can see that's no longer there. Same with the code.
It kind of depends on what we're using this project for. Some of these things are set up with the project template that we created, right? So because we created one from software development, it's going to automatically turn on code where we can link in some of our other development tools like Bitbucket or GitHub and things like that.
And then we have the apps. So we've looked. at apps before some of some of the apps in the marketplace should say I mentioned where you can go to discover and find those apps similar to up here I do want to point out the automation automation is something that we will look at later on in this course as well but this is where you can come in and start to automatically tell Jira to do things think of tools like if this than that or Zapier Jira has some of that automation built in automatically We'll look at that later on in this course when we're looking at it with a company-managed project, but we can also do that in team-managed projects here as well.
The concepts between those features like the roadmap and automation between company-managed projects and team-managed projects are really the same, similar to the issue types being the same. The big difference is what we learned earlier, where in a team-managed project like this, everything in here... lives in this project only.
For example, the idea issue type that we created doesn't live anywhere else but inside of this website 2.0 project that we created. So hopefully the gears are starting to turn for how you can customize your own team managed projects. And with that, we've come to an end of this section. I would encourage you to take some time between the sections now to play around with some of these features.
And when you're ready, we'll move on to company managed projects. and start taking a deeper look at a lot of the features and customizations that we can do in Jira. See you in the next section. In this video, we'll kick off this section by learning how we can create company-managed projects.
Now, the process for creating a company-managed project is very similar to when we created a team-managed project. So if you watched that in the last section, then a lot of this may seem familiar. But...
There is one key difference. You have to have Jira administrative permissions to be able to create company managed projects. Not everyone can create or customize a company managed project like you can a team managed project.
But if you are a Jira administrator, to create the project, come up to projects, create project, and then in here, just like with a team managed project, with a company managed project, the first step is to pick the project template. So this would go back to what we learned about earlier in this course. What sort of organization do we want for this? Who in our organization is going to be using this project? What are they using it for?
Are they going to be using a Kanban workflow, a Scrum workflow with sprints? And at this point, usually what I'll do as a geo-administrator is I'll sit down with a team leader or team leaders, if there's multiple teams that are going to be using this. project and get a sense for what their goals are. What are the things you're trying to track?
What sort of workflows are your teams using and the members of your team using? And what are the expectations for what this can get? And then from there, I'll figure out which template will get me most to that point.
And then later on in this course, we'll look at how we can start to customize some of the things that the template does with issue types and workflows and things like that. But the templates can get you part of the way there. Over here on the left-hand side, we have a lot of different templates in here.
And I'd highly recommend going through and just looking at some of these different templates, seeing what is available and what sort of templates you have access to. Because one key thing to keep in mind here, if we come in here and maybe come to one of these templates, we can see this template is currently locked. That lets us know that we don't have access to this. And that's because... I'm using Jira software for this course, and this template requires us to be using Jira Service Management, which is a product that has features that I don't have.
And so this template is trying to use some of those features, but I don't have the license for that. Now, if we do have Jira administrative permissions with access to billing, then we could unlock that and we could pay for that. That's going to be an extra cost.
With the license, that's something to keep in mind with that. But I just want to point out, if you see this lock, that just means it's trying to use features that your license currently does not have. So let's hop back to software, and I'm going to select a Scrum template.
And we can see what this template's going to do, some of the issue types. It's going to bring in the workflow over here on the right-hand side. So if we use this template.
Now we'll be taken to the project type. And this is something, again, that we looked at very similar to the team-managed project. The key thing I want to point out here, once again, just to reiterate this, is this part up here.
You can't switch from a team-managed project to a company-managed project or vice versa. So if we create a company-managed project here in this video, we can't switch that to a team-managed project later on. We would have to actually create a whole new project to do that. Okay, so let's go ahead and switch.
select the company managed projects, give this a name. So this would be our, say our marketing team is going to be using this project. And I do want to point out, so even though there's team managed project, it's called a team managed project, right?
You could still use company managed projects for the team. And as a Jira administrator, the benefit of that would be you can create issue types or workflows or statuses. that can be shared across multiple projects, multiple company managed projects, right? Instead of the team managed projects where everything is all encompassing in that one project.
And once we're happy with this, let's go ahead and create the project. And there we go. Now that we have our company managed project created, let's move on to our next video where we'll get familiar with what we're looking at here and how to navigate around it.
See you there. In our last video, we looked at creating a company managed project. So let's take a couple minutes to get familiar with the interface and some of the features that we have in a company managed project, starting with the left side menu.
So this first menu item is going to show us the other agile boards, either in this project or boards that we have access to across the JIRA installation. And this is important. This is a cool thing to keep in mind about company managed projects.
That's different than team managed projects is in a company managed project. We can have as many. boards as we want living inside of that project. We can see all of those right here.
Next, we have the roadmap. This is looking pretty empty right here because we just created this. And we'll be looking at this more in depth later in this section. But for now, just know that the roadmap is a high level way to see all the epics in our project and their status. So earlier when I was talking about the concepts of epics and stories and how they link to the...
to the epics, the epic itself can be a great way to see all of the stories or issue types that we've broken down to fit inside of a sprint. And then the epic itself, there may be more than one epic across the project. So the roadmap is a great way to see all those different epics, that then each of those epics are going to have other issues underneath them.
So it's kind of a hierarchy thing and the roadmap is just a nice way to get a really, really 10,000 foot big picture view of the epics in our project. Next, we have the backlog. So backlog is another Agile term relating to the Agile board.
So like we were learning earlier in this course about sprint meetings where our team decides what work is going to get done in the next sprint, that work actually is going to come from the backlog. Then throughout the sprint, as new things come up, they get added to the backlog since the team has already decided what to work on for the duration of the sprint. So the day-to-day is actually going to be done in this active sprint area.
And then as new things come up, those issues can get created throughout the sprint, but they're not going to show up on this board. They're going to show up in the backlog for the next sprint planning meeting. Now, I know there will be times where...
There are emergencies and things really have to be added. But the goal of the sprint is we've decided that this is going to be the work that gets done. If there's new work that comes in, then we're going to have to take something else off. That's just the workflow that happens because you can't make up more time in the day. We've already allocated all of the time for things to get done.
Now, under the reports is where we can find things like the burn down for the. scrum board. So the reports for a scrum are going to be different than reports for Kanban.
There are some that are pretty universal, the average age, how long it's been since it's from created to being resolved for each of those issues. I'd encourage you, we will look at some of these reports later on in this section, but I'd encourage you to take some time. There's a ton of reports in here. And of course, all the data is going to be different. The data that I'm using in, we said, we just created this, right?
So There's not going to be a lot of data for a lot of these reports, but the data that you have on your side as you're creating issues and as your workflows are going, then it's really cool to see some of these and see how they can start to see where some of the roadblocks are and start to break some of those down. Now, if we go back to the project, we have the issues. So this is where we can see a list of. all the issues that live in a project. So this is just a simple list of all the issues in the project that we can filter down by status, by who it's assigned to, things like that.
This is a very powerful feature. We're going to look at this again, more in-depth later in this section. But just know for now that this is where we can almost bypass the Agile boards and see just a list of all the issues that are in this project, that live inside of this project.
Go back to the project here. We have components. Now, components are a way to group together issues that are related. So let's say our website has a checkout system.
Well, that can be a component. So all the stories, bugs or any issues that are related to checkout can be easy to find. It's just grouping all of those together.
Next, we have code. So if we want to link this up with Bitbucket, GitHub, GitLab, you can see there are any source code management tools. We can do that and see those repositories very quickly here inside of Jira and start to see some of the branches, commits, and the pull requests and things like that. Releases are similar to components, but releases are, think of them more like versions, right?
So you can see it's starting versioning. So think of... Anything that is version 2.0 or version 3.0 of our website or app, all that can be tied to a release.
It can be super helpful when you're writing the changelog or things like that to see exactly what bugs, what stories, what issues were resolved in that release. So the project pages is really a link to Confluence. Confluence is a separate app from Jira, so we're not going to be covering it in this course. But just know that Confluence is Atlassian's wiki documentation tool.
So you can link a space filled with pages for documentation or whatever it may be in Confluence to a project in Jira. So that's what this is for, to be able to go back and forth with those very quickly. And then these last two menu items are pretty straightforward. We can add a shortcut.
So adding a shortcut either to, you know, the. certain repository, or I've worked with teams sometimes where they just want to add a shortcut to maybe another intranet or specific web pages that are of reference. And when you add that, you can see the website address and the name.
It's just going to add it over here in the left side menu. It's a quick way to navigate to that very, very quickly. Just a way to speed up your team's productivity.
And then last, we have the project settings. We will be looking at these more later on. in this course.
But just I want to point out here, one key thing here is you have to have administrative permissions to the project, not necessarily to Jira overall, but to this project you have to have administrative permissions to see the project settings. So if you don't have administrative permission, then on the left side menu, you're not even really going to see the project settings link there. Okay, so we covered a lot. But as you can see, there's so much more that we have yet to cover as we start digging into all these different features.
And we'll be looking at most of these more in depth throughout this section and later on in this course. But for now, let's move on to our next video where we'll have Jira create some sample data so we have some things to work with. In the past few videos, we've looked at a company managed project. And when we created the project, it came with a scrum board. However, we don't really have any issues in it.
So in this video, we're going to do a couple of things. We're going to look at how we can create a new scrum board in the same project. And while we're at it, we will also have Jira create some sample data so we have some issues to work with.
So let's start by creating a new scrum board in this marketing team project that we've created. So come over here to the board dropdown, click on create board. And the key thing I want to point out here is We can create a scrum board.
Come in here, click this button, and we'll do that here in a second. But I also want to point out we can create a Kanban board. Even though we used the scrum project template, we can create a Kanban board in that same project.
The template is really just how things are set up. From there, we can customize things however we want. And vice versa is true as well.
If we created a project with a Kanban template, we could create a scrum board in there as well. So let's create a scrum board. Now here, we need to tell Jira where we want to create this. So we do want this board to be created with a new project. That's basically what we did in the last video, except we went the other route.
We created the project with the board. This is creating the board with the project. End result is the same.
It's just a matter of kind of where you go to do that. We can create the board from an existing project, or we can create it from an existing saved filter. Now we haven't looked at filters yet. Those are essentially...
Think of them like saved searches. So we can create a board around a filter. And we'll look at how filters are a vital part to boards. And we'll look at those here in a little bit. But for this video, we're going to create the board from an existing project.
Now we need to give this a name. So let's call this our sample scrum board. Now we need to tell Jira two things. One. What is the project that we want this to be based off of?
Where do we want those issues coming from? So let's say... We want them to be coming from the marketing team.
And then by default, JIRA is going to say, oh, that's a project. We're going to have this live in that same project. We could change this if we wanted to.
If we wanted the issues on the board to be from the marketing team, but we wanted the board itself to live in the LaFeb project, we could change that. So they can be independent of each other. And this is where it's starting to, it can get a lot more complex, but you get a lot more customization of how you can organize things across these. company managed projects. All right, so let's create our board.
And there we go. We have this new board. Let me skip this. So it's the same as the other board, as you can see, because they're both scrum boards.
They're both blank scrum boards that we've just created. But we can customize these separately. So as we're going through some of the customizations in this section, just keep in mind that you can have multiple boards and different customizations for different boards living in the same project.
Okay, so now that we have this board created, let's have Jira give us some issues. So we have some data to work with so everything isn't completely blank like this. So to do this, I'm going to come up, come back to create board. And instead of just creating the board, I'm going to create the board with some sample data. Now, there is something to keep in mind here.
When we do this. it's going to create a new project, right? We're not creating it from an existing project or an existing filter.
We're creating a whole new project that's going to create that, put some issues in that project, and then also create a board, okay? So I'm going to say, we can leave this as a sample scrum project. That's fine.
Go ahead and create this. Now, Jira is going to go through the process of creating the project, creating the board. and creating a bunch of issues for us on that board.
So let's give it a moment to think about that. And there we go. So we have this, we have a bunch of issues on here, and we'll look at this here in a little bit, kind of get familiar with what we're looking at here. But for the purposes of this video, I do want to point out that we have this new project. that's been created, the sample scrum project.
You can see the ID key, SSP is that key for that project. And that's different than the marketing board or even the sample scrum board that we've created. You'll notice that these don't have any of those issues.
So let's move on to our next video where we'll get familiar with what we're looking at here and all of this. this interface and get familiar with the board itself. And then we'll get into customizing the board and how we can get issues on that sample board that we created, get these issues on that sample board that we created and see those across different projects. Alright, so I'll see you in the next video where we'll get a good overview of this screen here. In the past couple of videos, we've looked at how we can create Scrum Agile boards and company managed projects.
Now that we have a lot of data and a lot of issues on our Scrum board, let's take a couple of minutes to understand what we're looking at here. So as with everything with the left menu, you can see we can hover over, we can collapse or open this up. That's really the case anywhere here inside of Jira.
Just give us a little bit more room to see things depending on how many columns you have on the board. That's where I find it can be really, really helpful to collapse that if we need to. Up here, we have our breadcrumb so we can see where we're at.
Right. So this is the board that we're on. The board lives inside this project. And then this project is, well, it's a project. So we can access all of our projects by clicking on this breadcrumb link here.
And then down below, we can search so we can filter. the issues on our board. So let's say we only want to see the issues that have, if I could spell properly, detail in them. You can see it has details in the summary.
So this is the only issue that we're filtering. So just a quick way to filter all of the issues on the board. And then to the right of that, we can filter based on the user that that issue is assigned to.
We saw this. When we were looking at the team managed projects, it's the same concept here in the company managed projects. If we only want to see the issues that are assigned to me, to Dan, we can filter that or we can find any of the issues that are unassigned. Or if there are other people who have issues assigned to them, we'll see them show up here and we can start to filter them out.
You'll notice that it's actually additive as well. So we can add, see any issues that are assigned to me and unassigned or assigned to me and somebody else. You can add that as well. Right here, these buttons here may look a little different on your side if your Jira administrator has started to customize some of this. So these are called quick filters.
And these two right here are kind of pre-built. They're built in. But these are fully customizable. by really the project administrator can customize these as well.
It's just a quick way, again, to filter things. So only the issues that are mine or only the issues that have been updated recently, which recently, I think it's a day. We'll look at these board settings here in a little bit.
But yeah, updated. Yeah. So updated within the past day is what recently means. But we can customize that. And again, we'll look at customizing quick filters later on in this section.
Over here on the right side, let me clear this out so we see all of the issues on the board. Over on the right side, this is for automation. So we can start to add some automation to the issues on this board.
And we'll have a video dedicated to the basics of automation and how that works in the next section. But just know that you can access some of that here directly on the board. We can star this board. So we looked at starring projects earlier in this course.
It's the same concept. Think of it like bookmarking or favoriting. If you were to star this, if we go under your work, under the boards, you can see the recent ones that we've accessed.
But watch what happens when I star this. Now, if I come here, we can see it's always going to be up there. I need to actually refresh for it to update.
There we go. So we can see. This board has been started, so it's not in the recent anymore.
It's always going to be pinned essentially to the top of that menu. So just a quick way to access the board if we want quick access to that. To the right, we have how many days are remaining in the sprint. So this is going to be based on how long the sprint is. If you remember from earlier section, a sprint is a predetermined amount of time.
So if your team is sprinting for two weeks, And this is the first day of the sprint. You're going to have two weeks left, you know, 14 days left on that sprint. So this is just a quick way to be able to see how much time is left to get all of the issues on the board completed. Then to the right of that, we can complete the sprint. So once the sprint is over and we're going into our sprint planning meeting in the sprint planning meeting, we'll complete the sprint before we actually start a new one.
So that's this is where you can do that. We can share the board so we can share this with. anybody who has access to this project inside of Jira. So if you try to share this outside the organization and they don't have access to the Jira, then they'll be prompted to create an account or log in or whatever it may be.
They won't necessarily have access to that, but you can share this with your team members there. And then, of course, we have the three dots where we can change some more board settings. We'll look at that in our next video, actually.
We do have some insights here. So they can give us some quick stats about our sprint, what our current progress is for the sprint. Just a quick way to be able to see how things are going without going into the full reports or anything like that. Just a really quick way to see that directly on the board. Now, before we do get to some of those board settings, I want to hop over here real quick because a big part of a scrum board is the backlog as well.
So let's look through the backlog in this interface and kind of get familiar with this. You can see there's a lot of similarities. So the search, the filter based on a signee, the quick filters, the insights, the three little dots for the dropdown there to get to the board settings, all that is pretty much the same.
But we also have our backlog. So these issues are not in the sprint. Actually, you know what?
This might be a little bit easier just to walk through a sample process for what this sprint might look like. So let's say we're working. It's the last day of our sprint, right?
So we're in our sprint planning meeting. We're doing our next. We're preparing for the next sprint.
First step would be to complete this sprint. And so here, Jira is going to say, OK, there are three issues that were completed. You can see these three issues are done here.
Three issues that are still on the board that are not complete. So what should we do with those three issues that are not complete? Do you want to move them to the new sprint, which means it'll automatically put them on the new sprint to get done in the next? sprint, whether two weeks, a week, a month, however long your sprint is, or do you want to shift them to the backlog? So for this, let's actually add those to the new sprint so we can see what happens there.
Complete this. It's going to take us to the report. We can see how well we did. We can have that discussion over what went well, what didn't go well, start to see that, really start to see some of the issues, these particular issues that were done, some that were not done, and start to break that down more and really... get into some of the details of where some of the roadblocks may have been.
When we're ready to figure out what the work is for the next sprint, you can hop into the backlog and you can see the three issues that we had that were incomplete have automatically been added to the next sprint. If we want to filter these, we can filter them based on the team member, so who it's assigned to and in order to be like, Dan, these are the issues that you really need to work on getting complete in the next sprint, going through each person. We can see the versions.
So we can see the different versioning. Remember, we talked about what versions are, where we can group together issues. So we can see in version 2.0, where there are seven issues total, two of them are complete.
And there's still a couple that are on the sprint. There's some that are in the backlog. We can start to filter that down if we want to.
We can do the same for epics. So we can see all the issues that are in epics. There's currently no issues in epics.
We'll look at those more later on when we start to work with roadmaps and stuff. But if we have epics, it's the same sort of concept as the versions, just another way of grouping those. The same sort of concept as far as this display is here inside of the backlog.
Now, because we had Jira add those to a new sprint, automatically. We already have a sprint that's been created. We could create a new sprint if we needed to, if we didn't have anything here.
Or we can edit this sprint if we say, you know what, we're going to do two weeks. No, we're going to do four weeks. We can have a custom start and end date however we want to for that sprint.
And then the next step would be to add any issues that we need to. So if there's any issues that are in the backlog that we need to add, then now is the time to do that. So either we can left click and drag to bring that up, or we can use this little thing right here in order to drag it down and say, how many do we want to add? So maybe we want to add those three to the sprints. Just a quick way of doing that.
One cool thing to keep in mind, a little tip here, is we can do this using these filters as well. So let me show you what I mean. Let's say this here. I'm going to come in and let's assign this to Mary.
So we have a few different issues that are assigned to somebody other than myself. So now we can say, okay, here in the backlog, let me refresh this so we can see this filter update up here. So we can see, okay, now we have Mary up here.
So we can say, okay, Dan, it's your turn to go through the issues that you need. There's currently nothing in your backlog. We could create new issues if we need to go through that process. When it's Mary's turn. We can look at just hers and say, okay, these are the issues you need to work on.
Let's just drag those in really quickly rather than having to select them and do that. So it's a nice way of just being able to work a little bit faster when you're going through that sprinting process. When you're happy with things that are there, actually, I'm going to take these.
I'm going to hold down shift, left click, and we can drag those back out. So anything that's unassigned, we're only going to have assigned issues in the sprint. Now, the next step is to start the sprint, confirm that, yep, two weeks, okay, two weeks from today, start that sprint, and now we go back to that day-to-day process of taking those issues, working them through the statuses in the columns in order to get them to completion. Okay, so to recap, in this video, we got an overview of a Scrum Agile board as well as a quick rundown of an example sprint workflow.
Now in our next video, we'll look at some ways that we can customize our scrum boards. In our last video, we got an overview of a scrum board. In this video, we'll look at some ways that we can customize that board. Now, before we do any editing, let's make a note of what this board looks like right now.
So some of the issues that we have on here. So we have some issues. And subtasks, this is how you can see there are two subtasks under this story. That's what these are here.
And then we have some other issues, a bug, a story, and another story. So just kind of get a note of what we have here. So when we make some changes, we can see what those changes actually were. Okay, so the main driver for what issues we see on the board is going to be the filter.
So if you come into the board settings, come to general, we can see the filter for this board. And this filter query is really going to be the driver behind all the issues that we see on the board. So we can see all these issues here. These are the issues that are going to be on the board.
You'll notice there's a lot more here in this list. But you have to remember we have a... backlog. So let me show you what I mean by that. So let's come back into our project here.
I'm going to open this up in a new tab. So we have these issues on the board, but we also have more issues in the backlog, right? So the board is really just a way of filtering and displaying all of the issues that are in the filter.
So this concept can start to get... Pretty confusing pretty quickly. And this is really one of the biggest questions that I get from people who are new to Jira is because it's a bit of an abstract concept.
But if you think of, okay, there's a project, all of the issues live in a project, right? There might be multiple projects that have different types of issues, but all issues live in a project. And then a filter will filter that down.
It's a saved search. So what do we want? Do we want things that are only, maybe only in progress?
So now... when we see things, if we were to save this on the board, now we're only going to see those issues that are in progress. Even though we had some over here before, because they're not in progress, we're not going to see them anymore. As soon as I take this and move it, it's going to disappear because it's no longer in progress, right? So you can see, refresh there, and it disappears.
That's because the filter is saying, only show issues that are in progress. So let me save this back here. And then we can hop back, may need to refresh in order to bring those back. Oh, I forgot to save it.
Remember to save the filter. There we go. Now we can bring those back so we can see all those issues that we had there before. So again, all of the issues live inside of a project.
A filter is going to tell Jira. which issues you want to see on the board, and then where they display on the board will be determined by the board itself. So have we actually brought that into a sprint?
If not, it's going to show up in the backlog. If it is on a sprint, where on that board is it going to show? That's going to be based on the status of that issue. And we can customize that just like we saw in the team managed projects. if we come into the board settings, we can see how this is laid out.
So we can see, okay, these are the columns that we have. These are the statuses. So the statuses are tied to the issue.
And where do we want those to show up? So let's say, maybe for this, let's add in our QA status. And let's say we want that to be in progress.
Okay. We could add a new column if we wanted to. Or we can just have that in the same one.
And then if we head back to the board, now if we take an issue and drag it in, maybe to refresh, there we go. So now if we take an issue and drag it in, we can say, okay, we want this to be in progress or QA. And watch what happens. So this issue is currently to do.
Soon as I drag this over here, the issue is now in progress. So the status is tied to the issue and where you drag it on the board based on the board settings will determine what column has which statuses mapped to it. Now, a couple of videos ago, we created a new blank scrum board and there were no issues on it because it's in the marketing team project.
And this is one of the things that's really cool about company managed projects is. you can see issues from other projects on boards that live in a completely different one. So let me show you what I mean by that. Come over to the marketing board.
Let's go to the sample scrum board that we created, this blank one here. So this is going to have its own filter. So if we come into the board settings, change the filter and say, OK, there's no issues in here. That's why there's nothing showing on the board.
Because there are currently no issues in the marketing team project. If we want to show the issues in the scrum project, or maybe both of them, there's really nothing in marketing, but we could do both if we wanted to. Save this.
Now, if we head back to the board, open this up in another tab again, we can see now in the marketing team board, we have this project, this sample scrum board that we created that was blank. And now we have this set up. So this can be completely different if we wanted to. We can come in here and we can say. You know what, for this, I am going to add a column.
And this is going to be, this needs graphics, right? And maybe we don't have a status created for that yet, but we could drag this over and we can have that status map, just showing how we can customize this. Head back to the board.
And now we can see this completely different column that we have. So this is one of the huge benefit to company managed projects is we can see issues from multiple projects in one place like we are with this scrum board. And the last thing I want to point out about this before we get back to some of the board settings is because the status is tied to the issue itself. So this one here, let's remember this is SSP5, right?
So we are on the scrum board in the marketing team. Now, if we head back to where we were before, Let's head back to the completely different project. This is a different board.
And we look at SSP5. Let's say we take this and we're going to drag this over to done. Okay. So this is now done. Over on this board, this issue right here might need to refresh.
And we'll see that it will show up over here as done. The reason for that, because it was updated on a different board, that when we did that, we dragged it to the done column, even though it was a completely different board. it changes the status of that issue.
So this board here, because it's still on that board, this issue is still on that board, it says, oh, hey, wait a minute. The status of that issue has been changed. Doesn't have to be changed on this board.
It was just changed elsewhere. So now this board is going to reflect that difference. All right, now this video is actually starting to run a little bit long.
So let's move on to our next video where we can go back to the board settings and get an...