Atlassian Jira and Agile and Scrum Fundamentals for Beginners | Vlajko Knezic | Skillshare

Playback Speed

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

Atlassian Jira and Agile and Scrum Fundamentals for Beginners

teacher avatar Vlajko Knezic, Technologist and Methodologist

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

    • 1.



    • 2.

      Course Project


    • 3.

      Getting Free Access to Jira


    • 4.

      What Is Jira


    • 5.

      Agile In 5 Minutes


    • 6.

      Scrum In 5Minutes


    • 7.

      Understanding Jira Projects


    • 8.

      Creating Jira Project


    • 9.

      Project Settings


    • 10.

      Understanding Jira Issues


    • 11.

      Standard Issue Types


    • 12.

      Identifying Issues For Course Project


    • 13.

      Creating And Editing Issues


    • 14.

      Prioritizing Backlog


    • 15.

      Estimating Work In Backlog


    • 16.

      Creating Sprints


    • 17.

      Planning Sprints


    • 18.

      Starting Monitoring And Closing Sprint


    • 19.

      Finding Issues


    • 20.

      Advanced Search And Jira Filters


    • 21.

      Course Roundup


  • --
  • 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 starts from scratch, you don't need to know anything about Jira or Scrum!

Jira is Atlassian's powerful agile project management platform. You will learn this amazing product from the ground up in this course!

Join this comprehensive and free Jira course and benefit not just from the course content but from the hands-on approach as well!

Get your own free instance of Jira and a good understanding of how to use Jira to create and manage Scrum projects.

This course will teach you all the fundamentals about agile, scrum, projects, epics, stories, tasks, bugs, backlog, sprints, and much more! We will create a complete project fully from scratch, and most lessons are backed up with a hands-on tutorial. All examples showcase the features of Jira and explain how to apply them correctly.

Specifically, you will learn:

  • What is Jira, and what should it be used for

  • How to get access to 100% free instance of Jira

  • Basics of Agile and Scrum

  • What are Jira projects and how to create them

  • What are Jira issues and how to create them

  • Differences between epics, stories, tasks and bugs

  • What is Backlog and how to prioritize it

  • Estimation and capacity planning

  • Planning, creating, starting, monitoring and closing Sprints

  • Finding Jira items using simple and advanced search

  • Creating Jira filters

  • and so much more!

This curriculum covers everything you'll need to know to get started with Jira, along with a few incentives. At the end of the course, you will have hands-on experience with all Jira core features and your own free instance of Jira to experiment and extend your knowledge.

I hope you're excited to dive into the Jira and Scrum with this course. Let's get started!

Meet Your Teacher

Teacher Profile Image

Vlajko Knezic

Technologist and Methodologist


As a seasoned 20+ year career technologist, Vlajko has led high-performance teams, ranging from technology infrastructure engineering design & support to web development teams and product development groups.

Vlajko's career has spanned experiences as a developer, project manager, product manager, technology director, agile evangelist, and methodology leader.

He has helped many organizations improve the efficiency of their delivery by using the right tools and processes, and that knowledge and experiences are reflected in his courses.

See full profile

Level: Beginner

Class Ratings

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

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. Introduction: Hello and welcome to the Jira as cram fundamentals for beginners course. If the work you are doing is in any way related to information technology, you must have heard about the Jira, a great product from a classroom. Sometimes it is described as a bug tracking tool, but also as a project management tool. It is said that Jira is used for scrum management and also for support ticket management. It can be very confusing unless you have actually use JIRA. This course will provide you with a very clear perspective on what JIRA actually is and how to use it. The course, I will walk you through gyrus main features and terms and that we'll touch on Agile and Scrum, two concepts on which Jira very much depends on. This course is a beginner level course. However, even if you use Jira little and would like to get a broader understanding of this great product. You will still find value in the course. After completing the course, you will be familiar with the basics of Agile and Scrum. And you will fully understand what the Jira is, what it does, and how to use JIRA in your Scrum projects. This is a hands-on course, and through the course, you will build a full project using Scrum concepts. So we will start with the overview of our course project. Then we will go through step-by-step instructions on how to get completely free access to Jira, followed by a brief overview of JIRA. After that, we will wrap up the first section with a five minute crash courses on Agile and Scrum. In JIRA. Nothing exists outside the project. And in the following section, you will learn about the Jira project concept, how to create a new project and various project configuration options. Jira issues are building blocks of everything in JIRA and you will get a thorough understanding of issue general concepts as well as different tissue types such as epic story, bug in task. We will then immediately apply that knowledge to our course project, identify issues that covered the project requirements and create them in JIRA. The following two sections are various crime centric. We will create the project backlog in JIRA and you will learn how to groom backlog by prioritizing and estimating effort. You will then use group backlog to plan sprints, after which you will create sprints in JIRA and you will allocate all issues two sprints while maintaining balanced effort and dependencies. We will then run a couple of sprints by starting them and finishing them while reviewing a couple of carbon scenarios and reflecting on how to handle them in JIRA. And we will wrap up by learning about different ways to find the issues in JIRA, starting from simple project-based searches all the way to using advanced search with JIRA Query Language and creating filters for repetitive searches. I hope you will decide to register and take this course. And if you do so, during the next 90 minutes, you will find valuable content that will help you start using Jira right away. This course is totally free, and if you do like the course, I would really appreciate you taking few seconds to rate the course and help others interested in JIRA find it and get the same value as you did enjoy the course. 2. Course Project: In the course introduction, we mentioned the course project and how it will help you learn to use Jira. Let's discuss this project in more detail before we get deeper into the course. So what is our project? We have been tasked to create a plan for the development of a relatively standard online store website. Once completed alive. This application we will have the following features. Allow users to browse products for sale either as an anonymous or logged in user. While browsing, users can add products to their personal wish-list or shopping cart. Users can purchase items and pay by credit card or PayPal. Should the user decide to purchase items in the shopping cart, it will have to log in or create an account if they don't have one already. Users can set alerts of the price for items in their wish-list and receive e-mail notifications when the price changes. This project, we will use very valuable Jira features creating the project from scratch. We'll provide you with an excellent context for becoming familiar with those features and start using them in your projects. We will use epics, stories, and tasks to capture a defined requirements backlog to estimate the prioritize work, springs and boards to plan, organize, and manage work. As you can tell, all jira Core elements will be covered. And as you're following along, you will be creating and modifying all these things yourself. As you progress through core sections, you will be incrementally applying the knowledge learned in each section to our project. You will be able to understand how it can be used in real-world situations. Immediately. Before we start doing all the work, we will ensure that you have a JIRA Instance to follow along. Do a quick overview of JIRA and review critical Agile and Scrum cost centers. 3. Getting Free Access to Jira: These days there are many free plans or free licenses or free accounts for almost any software in the world. Naturally, anything that is free comes with some limitations or constraints that be a limited type of usage or limited functionality. For example, it is rare that softer with worldwide recognition is offered in a free package with no time limits and no compromise functionality. And this is exactly what Atlassian is offering in its free G right Conference package. You can get access to both of these applications with full functionality and no time constraints. Absolutely free, interested in learning how to get the software. This video will teach you everything you need to know to accomplish that. You will start from the URL that you see on your screen. Enter it in your browser, and you will end up on this page. Now, let's confirm for a moment, what is the deal you're getting from it last year? The free plan you are subscribing to allows you to have up to ten users, two gigabytes of storage, which will be used mostly by files you are, you will be uploading. Very important note, no need for a credit card. So you don't have to worry if some changes unexpectedly appear in a couple of weeks. Last but not least, you are getting access to two products. Juror is already selected and you have a choice between Confluence, Jira Service Management for the second product, I will choose Confluence. But if you'd rather explore or use Jira Service Management, you can absolutely go for it. Click Next and you're asked to select how you would like to sign in. Again, you have two options to choose from. Use your Google account authentication or proceed with an email password combination. If you opt for the latter, you will be asked to provide an e-mail address, create a password, and provide your first and last name. That will become one more set of credentials to remember. So I will opt for a Google account and select that option. If you decide to follow the same path, which I recommend, you would also be asked to login to Google. And I will do it now. If I did it right, I would arrive on the screen whereby full name is confirmed and I'm asked to consent to receive newsletter from a classroom. You can opt out, but I recommend checking the box and often gain because the content being scientists usually good quality and immensely useful. I will check the box to provide consent, and I will click on the Create Account button. The provisioning of Europe last year and the count starts at this point. And it can take a bit of time to complete, but it should be finished within 30 seconds. Once it completes, I will provide my site's name, which eventually becomes a sub-domain of it last, they will use as my site address. You can use almost anything with only one constraint. It cannot be already used by someone else. If that is the case, you will be warned and asked to use a different name. In general, you want to use something familiar to you. Or if you will be using this JIRA Instance for business purposes, something that resembles your company name. When done, click on Continue and provisioning of your Jira and Confluence instances. We'll start. That process can take a couple of minutes and then we'll stop the recording and continue when it completes. Now your products are almost ready and you're offered to invite your team members to join us. Well, remember that the free package allows you to have up to ten users. So don't worry about the extra charges if you consider sending the lights. Besides inviting specific people, you can also decide to allow anyone having good email address with the same domain as your ears to join. That option should be turned off to avoid surprise charges. You can always send these invites later. So I will skip this software for now. The last step is to answer a couple of profiling questions that will help JIRA to do the initial setup to better suit your team's needs and level of familiarity with Jira and digest. After hitting next, based on your responses, you'll be offered a template to use when creating your first Jira project, but you can also select a different one. I will go ahead with the Scrum templates. On the next screen, I'm asked for the project made. And once I QI team, I can click on the Create button. And in no time this project is created, you might get many pop-ups with information about various tutorials. The content of these pop-ups can vary based on your responses to profiling questions. You can browse and see what is being offered, or you can just ignore them. Regardless, at this point, provisioning go JIRA and confidence is completed. And you can start using them using the Application menu in the top left corner, you can easily switch between JIRA confluence and your site administration where you can manage users and your Atlassian and subscriptions and billing. And that is all you can navigate back to JIRA confluence and start using them to create great things. 4. What Is Jira: Put simply, dura is a software platform for organizing work AT teams, doing the work around tasks and projects. Jira is very good at managing the scope of the work priorities at task assignments. It is mostly used its software development, but it is in no way limited just to that. In JIRA, work tasks are defined using Jira issues. There are several predefined issued types, such as epics, stories, tasks in bugs. Jira is very agile centric, and that is where the specific tasks types cup are coming from. However, custom types can be defined as well. Issues can be prioritized before processing, and they are processed from creation to completion through predefined and customizable workflows. At any point in time, any issue status can be conveniently viewed on project boards that are also customizable. Issues can be assigned to team members and work effort for each issue can be estimated. Many other issue attributes such as priority at dependencies can be set at the full history of issues He's preserved. Users who are in any way associated with an issue can be automatically notified anytime something with the issue is changed. Issues are organized in projects. Jira projects are coupling together. Issues, workflows, and users working on the stories. Out of the box, Jira provides many ready-to-use project templates, such as Scrum or Kanban for software projects and quite a few for business projects, for example, document approval or recruitment. Each template provides issue types and workflows optimized for the specific purpose of that project. Many reports in JIRA are available out of the box. A lot of them are related to Scrum concepts such as velocity, burned down and burn up charts for project release or sprint. While others are fairly generic, like time tracking or user workload. Jira allows for creating custom boards for more focused communications, such as only completed issues or non started issues. Jira can be customized to a considerable extent. Almost anything Hegira can be customized, including issued types, fields, screens, workflows, et cetera. Customization can be done on the global level affecting all projects in an instance, or it can be limited to a specific project. Jury is often used in conjunction with Conference, which is a different software platform used for team collaboration and document management. Both confidence and JIRA, our products from the same company, Atlassian confluence in Jira, do not need each other to do all the great things that can't do. However, with connected, they can do much more at a, tremendously improved the efficiency of the teams working on projects. For instance, someone viewing a project report in Confluence can have real-time information about the progress of project tasks, manage the Jira. It goes the other way as well. Someone working on a development task in JIRA can view a solution design document created and managed in Confluence without switching between two applications. In the next tower, we will cover almost every feature mentioned in this overview. This is a hands-on course at Union learned all these features, but try them yourself. To do that, you will need access to a JIRA Instance, and I will show you how to get that. As mentioned earlier, JIRA is very agile as crops centric. Therefore, in the next lesson, before proceeding any further with Jira, we will do a quick overview of Agile and Scrum. 5. Agile In 5 Minutes: So what is it about the agile that has caused thousands of books, conferences, and presentations on the topic. And if there is that much to say or discuss how it can be covered in five minutes? Well, the answer is yes. It can be covered in five minutes and no, there is not that much the same edge l can be covered in five minutes because Agile is not a methodology. It is neither a process nor a framework or a tool. So there is not that much to learn, but there is a lot to understand. Agile is a software development philosophy based on this set of four values that can undoubtably be explained in less than five minutes. The best way to understand what Agile is about is to read or reread the Agile Manifesto. Agile Manifesto is the document created back in early 2001, when 70 liters in software development got together in Snowbird, Utah to discuss the future of software development. The group's members shared frustration about the current state of affairs, even if they disagreed about how to remedy the situation. They agree that the problem was that companies were so focused on excessively planning and documenting their software development cycles that they lost sight of what really mattered, pleasing their customers. Agile Manifesto emerged from that discussion, and although it ended being only 68 words long, it captured the essence of the problems. For Agile values were established on that occasion, and they are individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration, over contract negotiation, responding to change over following a plan. And what disclaimer followed, which says, that is, while there is a value in the terms on the right, we value the terms on the left more. Another way to read the manifesto could be something like this. Tools and processes are important, but it is more important to have competent people working together effectively. Good documentation is useful in helping people to understand how the software is built and how to use it. But the primary purpose of the software development is to create software, not documentation. A contract is important, but is no substitute for working closely with customers to discover what do they need. A project planning is important, but it must, it must not be too rigid to accommodate changes in technology, environment, stakeholders priorities at people's understanding of the problem and its solution. There are endless examples of projects thoroughly plant using the prescribed tools and processes that eventually failed big time. Thousands of pages of outdated, wrong, or irrelevant documentation, Thousands of signed contracts with agreed upon clauses completely missing. Why contracted work was actually needed. Thousands of software applications that work as planned, but not doing what users actually needed. Agile values are bad to address those problems regardless of the methodology or tool or process. We will reflect on this throughout the course as we progress work on our project. Today's Azure landscape can seem cluttered with methodologies that promise to take agile ideas. It turns them into real-world implementations. But today's methodology badness isn't anything new. The manifesto itself was born out of a need to find common ground among Scrum. Extreme Programming, crystal clear at a few other frameworks. All those methodologies existed before agile came. So to understand the agile, you don't need to understand Scrum or Kanban or any other agile methodologies. In fact, you don't need to know anything about any of those. But to properly understand either one of them, you need to start with those for Agile principles, crafted back in 2001. 6. Scrum In 5Minutes: You might wonder why there is a lesson about Scrum when this course is about Jira. The reason is that Jira is by default, very much Scrum centric and a lot of existing jury implementations are following scrubs structure it concepts such as user story and backlog sprint. Scrum configuration in JIRA is not mandatory and there are other available configurations, but it is by far the most used one. So what is Scrum? Scrum is often labeled as a methodology and the framework and many other things. However, establishing the best classification is a pure academic think. The important thing is that such classification is not at all critical for understanding Scrum. So to move forward, let's agree that Scrum is a set of well-defined thermoset processes widely used in software development to define, plan, execute, and deliver applications. This is certainly not the officials craft definition, but it is a solid one. The basic breve salt scrub, similar to other Agile frameworks, is to acknowledge that precise planning is impossible. Directional planning is efficient. Overly detailed documentation is outdated. The bottom-left, it is completed. Working software at communication with customers is much more important. That plans at the documentation. Here is how Scrum works. The product owner, who is a team member responsible for defining and prioritizing requirements, will write a set of user stories to capture desired features. A good user story should provide information about who needs of functionality, what application needs to do, and why it is required. An example can be something like as an online store user, I need to filter products by category so that I can foster find the product of their time. Looking for. Sentence structure does not have to be this rigid. The bottom line is that a good user story has information about who, what, and why product order. We'll write as many stories as needed in all of them will be placed in the product backlog. The product backlog is another sculptor and it represents a place that contains a description of all work that still needs to be done. It has not started yet. While creating stories, a product order will continually groom Product Backlog, which means that more important stories you'll be kept at the top of the pile at up to date. When there are enough stories to start planning the development work. The whole team, including the product order, developers, testers, and scrum master, will get together. Scrum Master is a scrum specific role that is a person responsible for ensuring that Agile principles at scrub processes are followed. Add obstacles to completion of the stories that inevitably arise over time are removed. The whole team will review and discuss stories. Remove any ambiguities, make necessary adjustments through stories at estimate the effort, dots the duration, effort required to cooperate each story. Once backlog review is completed, the team will start placing stories in springs. They will be creating a sprint backlog. Sprint is a defined period of time, usually two weeks or three weeks, during which a specified chunk of work will be completed. A team will work on a specific set of stories during a single sprint. Nothing more, nothing less. The expectation is that all stories included in a specific sprint will be fully completed by the Spirit. And therefore, part of the sprint planning is to select the right About of stories based on the team's capacity and therefore required to complete those stories. In other words, the team should plan to do as much work as they can't complete in a single sprint. No more, no less. Once a sprint is completed, the T moves to the next sprint, which already contains another set of stories. This cycle keeps going while there are stories left in the product backlog or a decision was made to stop the development. This level of explanation of Scrum certainly does not cover all elements. It processes that are part of Scrum. Still, it provides you with enough context to understand the key terms such as backlog, Sprints and user stories. When you see that what JIRA screens. If the remaining lessons of this course, you will learn how to use JIRA to manage this type of development process. 7. Understanding Jira Projects: If you are taking this course, you are probably somewhat familiar with the concept of projects unrelated to the specific methodology or methodologies you might have been exposed to your work. A project can be viewed as a series of tasks that need to be completed to achieve a specific outcome. That outcome could be a mobile app and your website for a marketing agency. Migration of enterprise applications from one cloud provider to another, anything. Regardless of what the project is, there is always a set of defined tasks that need to be completed before we can get the outcome we expect it at the beginning of the project. That being said, a Jira project also consists of a set of tasks. But on top of that, it also includes certain rules regarding the process that is followed to complete the tasks. It also adds consideration for people who are working on these tasks. Hence, we can say that Jira projects consists of three components. Tasks, also called issues in general terminology, which represents the work that needs to be done. Workflows, which are sets of predefined steps and statuses that tasks go through from creation to completion. And people who are working on those tasks. As we're going through the course lesson, you will learn about all three components of a project. At this time, let's look at a couple of examples for each of the components. We will start with tasks. Our course project is the creation of the website for an online store. And as we discussed in one of the previous lessons, one of the requirements was allowing a user to have a wish list of products available in our store. To meet that requirement, we need to write the code that to provide at least the following functionality. Add item to the wishlist, remove items from the wish-list and view wishlist. Each of those represents a piece of development work that needs to happen to fulfill that requirement. In JIRA, these three items will be presented by jira issues or tasks. No tasks can be completed without someone doing the work necessary to complete a task. During the lifetime of a Jira project. Tasks are assigned to people, team members to work on them and to complete them. For example, our developer, Johnny, we'll work on Add Item 2 wishlist and remove item from the wishlist tasks. While n will work on view wishlist task. People who are working on tasks and progressing them are the third component of a Jira project. At the beginning of the project, these tasks are planned out and waiting to be done. They remain in todo status until someone starts working on them. It can take any number of days or weeks of work to complete each task. During that time, a task is considered to be in progress status. Once all the work is completed, the task both to Done status and ends its journey there. The journey or progress itself from to-do through in-progress, and then to W1 is an example of a workflow, that second component of any Jira project. As you go through the course, you will learn more about the Jira projects. What we covered in this lesson is sufficient to proceed further. The main point to be taken is that any Jira project is a tool that brings and keeps together tasks, workflows, and people. In fact, you cannot do anything in JIRA without the project. So before we can proceed any further, we need to create the project to hold together our tasks, workflows, and people. We will do that in the next lesson. 8. Creating Jira Project: In this lesson, we will create the Jira project which we will use throughout the course while working on our online store. First, go to the Projects menu in the top navigation. And when he toppings, click on the View All Projects menu item. There is also the Create Project link, which works perfectly fine. But don't use it at this time. After clicking on view all projects, you will end up in the project screen. If you just created your Jira account, this screen will be empty. And if you already had a Jira account, there could be some older projects of yours already there. There is the Create Project button at the top right corner of the screen. Let's click on it and you will be asked to select the project template. But what is a project template? The best way to describe a project template is a collection of issue types, workflows at boards optimized for a specific purpose. The difference between the templates is mostly about types of JIRA issues and associated workflows. For example, user stories and tasks in the Scrum template or support requests in the help desk template or document in the document approval template. Templates are categorized into specific segments such as software development, service management, project management, marketing, legal, and few others. As you browse segments in each one, you can see available templates and a brief description. But when you click on specific one, you will get a detailed explanation of that templates features which it should types are included, and which workflows are available. We will go back to the software development category and we will select the Scrum template. And then we will click on the USU template button to confirm the usage of this template. On the next screen, you'll be asked to choose a project type. You can choose between the team managed and company managed project types. These are new names for what used to be called NextGen and classy projects. Team manage projects or next-gen projects, are a relatively new concept in JIRA. Currently, they have fewer features available then company managed projects, as you can see here. Some of those features like custom workflows and custom quick filters are essential for efficient usage of Jira and we will cover them in this course. Also, the general use of team manage projects is still well behind the usage of classic projects. For all these reasons, we will continue with the company managed project. So let's click the button to select it. In the next screen, you need to provide the project name and project key. The name should be reasonably short, but descriptive enough. So let's call our project top store. The project name must be unique and Jira will warn you if you try to assign a duplicate name, notice that a key field gets prepopulated. The project key will be used as a prefix to numbers assigned to users stories in that project. It should have the value of Ts and you should not make any changes to it at this point. Just below is an option to share settings with another project. This feature allows you to clone project configuration from a different project. Project configuration includes things such as issue types, workflows, screens, etc. We will go through configuration options shortly. It for now, we'll leave this checkbox unchecked. There is also an option to connect to work across your tools. If enabled, the project we are creating will be connected to other Atlassian and tools such as confluence and Bitbucket available under the same license. You can leave it unchecked for now. Click on the Create Project button and you are done. You have created a Jira Scrum project. In the next lesson, we will review various project configuration settings. 9. Project Settings: Jira is extremely configurable software to say at least still, you can start using it out of the box with all the default settings. In this course, we will do that because we will follow the standard Scrum process. And as we said earlier, scrum is one of gyrus default configurations. However, if default settings do not suit your needs, you can also make configuration changes of various complexity and impact levels. You can make changes that affect your whole JIRA Instance or just a specific project. Projects specific configuration changes are done in the project settings section, which we will review in this lesson. The project settings section is huge. There are almost 20 screens that cover various configuration options. And this is a beginner course. Therefore, we will not detail every screen, but I will show you each one and briefly describe what is it used for. The first green is the details. This screen contains configuration settings that you're most likely to change for your projects. Should you decide to change your project name, this is the place to do it. You can do it safely anytime, as often as you want. Below is the key field which is not advisable to change, especially after you have created issues in the project. It contains the prefix that is added to each project issued number and changing it can't create it valid URLs for project issues and a lot of headaches. Project type shows the type you had selected when you created the project, and it is not editable. To change the project to a different type, you would have to create a new project and then move all tickets. Project category allows to group together projects of the same kind. For example, marketing projects or software projects. It does not have much functional value except edit ability to filter projects by their category in the whole project screen. Avatar is an image that will be rendered beside the project's name. On all Jira screens. It is followed by the description, which as the name tells, is used to optionally provide a short description of the project. The next field is the project lead, which represents the user who will be the main point of contact for this project. The last field is the default assignee, which determines a user to whom all new tickets are assigned. There are two options to choose from. Project Lead or no assignment at all. People screen is next. And it is used to configure permissions specific to this project. This functionality is fairly limited in the free plan, but on the other place, this screen allows assigning different project provisions to specific sets of users. Automation is a new feature where you can set up rules to automate actions, such as marking epic done with the last of its issues is marked done, or assigning an issue to a specific user. If it's title contains certain keywords. As its name says, the summary screen is a summary of all configuration settings for this project. Issue screen is used to configure the issue type scheme, which defines the types of issues used in this project such as stories, bugs, or tasks. I will cover JIRA issues in greater detail in the next section. Issues layout screen allows the configuration of visibility and layout of the fields for each issue type. It is specific for the issue of view which was recently introduced the Jira, and by the end of March 2021, will completely replace the legacy issue of you. The workforce page is where a specific workflow can be defined for each issue type. For example, including in testing status for user story and not for the task. The screens page is where the field layout is defined for the legacy issue view. I mentioned a moment ago that the legacy issue of you would be phased out by the end of March 2021. And this page might be gone as well at that time, the field screen is used to configure individual fields for each issue type. For example, if you would like to be able to assign JIRA user as a designated tester to each bug. You would create a new field called QA assignee and edit to the bug issue type. Code screen is a place to connect the Jira with a code repository in GitHub or Bitbucket. And it enables linking JIRA issues to specific code commits and pull requests. Deployment screen allows to integrate code deployments tools and have visibility from JIRA in deployment history. Versions or so-called releases. As JIRA inconveniently has two names for the same feature is used for packaging JIRA issues into deployment bundles, which is excellent for keeping track of was a specific issue deployed into a specific environment. Components are a way to group JIRA issues into specific sets such as database for database related issues or, or API for API related issues. Once a list of components is defined, the component field becomes available in the Issue screen. A Genie is a class yes, alert management system and it can be integrated with Jira issues. Right now, I don't have that integration configured here. Permissions and issue security screens are used to define to a very granular level, specific permissions based on user group. The free Jira package does not include this functionality. Notifications page is where we can define who will be notified when specific events happen. For example, when a comment is created in an issue, the issue of assignee and the shoe reporter should be notified. The development tools screen is another place to connect Jira project to various development tools. Issue collector is a feature that allows embedding a form into any website which can create the Jira issue from information collected in the form and submitted from the form. The slag page is where Jira can be connected to Slack and enabled to post messages about issues activity in a Slack channel. This concludes the section about the Jira projects. We have created our course project and we have glanced through numerous project configuration options provided by jira. The project is still completely empty. But now we can start defining and planning these projects work. In the next section, you will learn about JIRA issues, different tissue types, and how to create and manage issues. 10. Understanding Jira Issues: If you are somewhat new to JIRA and see the issue or issues on many screens. You might be wondering what JIRA issues are, what are different tissue types, how to use them, and what are JIRA tickets? In simple words, teams using Jira software utilize issues to track individual work items that must be completed. Depending on how a specific TV uses Jira. Issue could be anything that would eventually get some as attention required to achieve some sort of completion. That is a bit of an academic statement and it is quite abstract. So let's try to use some specific real-life examples to help describe the concept. For instance, if you plan a vacation trip, you might have a list of things that you need to do before the start of vacation. Those things would likely be some or all of these research, destination, send deals, book, personal time off at work, book airfare, book hotel accommodation. By travel insurance, book boarding, put the dog. You can probably take care of all these things without creating a Jira projects to manage your vacation preparation. But if you actually do end up going that far, each item from the list will be covered. Jira issue at the start with the list is created. All these issues will be in a pending status waiting to be dealt with. Eventually, one after another. Someone will work on them to get them done at their status will change to complete. If you want to be more precise, you can introduce the progress status for each issue you started working on, but he had not completed yet. Let's go through another example. One more suitable to be Madison Hegira. Say you're working on a software project and you are asked to close the remaining gaps in the user authentication system. These gaps are described in an email and they are lack of functionality for a password reset at changing the email address. Also, the fourth number should be added to a user profile. They're also not problems regarding allowing usage or the space character in the username and validating the user David, select these, not working. On top of that, you're also asked to ensure that all user records that have not been activity the last five years are deleted and the user database is indexed. That can be translated into another list of things that need to be done. And it goes like this. Enabled password reset, enable email address change. Ed for number 2, a user profile. Username should not allow space characters, username length should be validated. Delete users not activity the last five years. Re-index user database. Although short, this list is a good candidate for Tracking JIRA, it is clear that each item will be covered Jira issue. But there are several issued types to choose from. Before we start creating issues for our old course project Hegira, let's review what these types are it how items from the list, batch them. We will do that in the next lesson. 11. Standard Issue Types: The first issue type is the story. And it is used to describe a new functionality and new feature, something that users will, will care about. Looking through our lists. First three items, enabling password reset and email, others change and edit. Phone number certainly qualifies as something users are interested in. Let's mark them as stories. But what about the remaining items? Will users, like your application? More spaces are allowed, the username, or if inactive users are deleted? Probably not. So items four to seven are definitely not story type. Next issue type is bug, which represents something that does not work as expected and needs to be fixed. A problem that we have at what to correct items 45 are clearly Sufi that falls into that category. You wanted the username to be validated. It space character not allowed in it, but for whatever reason it is not working, it needs fixing. So these two are becoming bugs. The last issue type is task, which represents work that needs to be completed. But it is not the feature that users care about it either. It is a work to fix something that is currently not working as expected. The last two items, 67, qualified because you will be doing that to keep your good health, not to correct a problem or to please a user. I will take item 6 and 7 as tasks. We mapped all our items in the list. But there is still one more issue type, the epic type. Often we refer to a group of features as a feature as well, silently assuming it is clear to everyone that there is some sort of hierarchy in place. For example, shopping cart is a common feature e-commerce applications. Still, there is a set of features that all belong to a shopping cart. Adding items to cart, or remove the, removing items from current or adding multiple items or showing related items and many more. That is where epic becomes useful. It is used to group related issues under one umbrella issue. In the previous example, shopping cart to become an epic and all other items mentioned like adding and removing products to and from the shopping cart will be your stories or other issue types. Let's see how to apply that to our example. When we talk about username and password, that is all part of user authentication functionality, which becomes our APIC. I times 145 seem to be a good fit for that. They should all be locked to a user authentication epic. User profile functionality is about maintaining a user record, including name, address, phone number, etc. Items to three, email address change and phone number are definitely part of that. So let's relate them to the user profile epic. Two remaining items don't seem to belong to any higher level functionality. So we will leave that without the epic, which is perfectly fine. Belonging to an epic is not mandatory. Now, after completing this lesson, you should have a solid understanding of the differences between standard Jira issue types and how to decide which one to use for a specific task. In the next lesson, we will put that to work and finally start populating our project. Two editions. 12. Identifying Issues For Course Project: You've just learned what a user story is, what EPA case, water bugs and tasks. In this lesson, we will put that to work and define the initial set of JIRA issues for our course project. Let's have a quick reminder about the features that we are expected to deliver for our online store. Allow users to browse products for sale either as anonymous or a logged in user. While browsing, users can add products to their personal wish-list or shopping cart. Users can purchase item and pay by credit card or PayPal. Should the user decide to purchase items in the shopping cart, we'll have to log in or create an account if they don't have one already. Users can set alerts. So the price for items in their wish-list and receive e-mail notifications when the price changes. There is no single right way to break this down and epics stories. However, for the purpose of this course, it is irrelevant how it was broken. As long as we have a meaningful structure that covers the scope. With that divide, here is the proposal is top epics that we will proceed with account management, searching products, viewing products, shopping, cart management, purchase management at wishlist management. But how do we know if the set of epics covers the scope defined by the requirements to co-author that we should map each requirement to epic or epics that are addressing the requirement. For example, to fulfill the allow users to browse products for sale either is anonymous, are logged in user requirement, we would need features into epics. Account Manager at epic will handle as an audible or logged in user part and searching products. Epic, we'll cover the allow users to browse products for sale part. The next requirement, while browsing, users can add products to their personal wishlist is covered by 20 ethics. Viewing products epic colors, while browsing, users can add products, phrase. And wishlist management handles add products to their personal wish-list or shopping cart. Wants the bad thing is complete for all requirements, we will end up with the BAP similar to this, which will ensure that nothing from the scope was missed. This map is attached to the lesson resources that you can download it and print it for your reference. Before moving on, I will add two more epochs. They don't relate to any of the functional requirements, but they're needed to contain the work for nonfunctional requirements such as alerting and monitoring. And that is exactly what the two epics are. Alerting and monitoring. All looks good. And we can proceed to the next step, which is defining specific stories. We did the epochs. Again, there is no single right way. It here is one of the correct ways to do it. For example, for the scope of Account Manager at Epic, we want to have the functionality to do the following things. Create account, login, logout, change evil At Reset Password. And for searching products, epics, we expect to be able to search products by category, search products by name, and search products by price. Of course, there are other ways to search for products, such as the number of sales or number of reviews. But since those features are not included in this list, they are not part of the scope and should not be considered. This list is also attached to the lesson resources available for download and print. This breakdown is solid enough to get us going. And in the next lesson, we will use this structure to create the initial set of issues in JIRA. 13. Creating And Editing Issues: We have identified our stories and tasks and the this lesson, we will create them in JIRA. First, let's make sure you are on the backlog screen. Once there, we can move on. I will start with Epics first, followed by other issues. In the backlog screed epics are contained in the epics panel and you can get to it by clicking on the little epic thumbnail here or selecting the show epics panel option in the screen actions pop-up. Clicking on the create epic link brings up the create epic pop-up. I have to give the epic a name at the summary. The summary field is a bit of duplication of the name. So let's center account management in both fields. Click on the Create button and epic is created. Let's use the same steps to create another epic. Click on the create epic. Enter searching products in both fields and click on Create. Don't worry if you see more fields in the create epic pop-up. Like many things in JIRA, discrete is customizable. And if you're not the only user of your JIRA instance, someone might have customized the screen regardless name and summary are the only two mandatory fields in epic. I will stop the recording while I'm creating the remaining epics. And if you're following along, you should pause the video, create that picks, add resume the video. Once you're done. Our eight epics have been created. And you can see that all the epics panel. Now we can move on to creating remaining issues. There are several ways to create JIRA issues and we will review a few of them. Let's start with creating an issue from the Epic Panel. Expense, the account management epic by clicking on the little carrot symbol beside it, the Epic Panel opens up and at the bottom there is the create issue in epic link. Click on it and the Create Issue pop-up will open. Notice that the selected issue type is story. Just below is the summary field, which is where you would enter the name of the story. Enter create a cow out there. The description field is where you would provide the full description and details about the epic. I will leave it empty for now. For the sake of time, the reporter field captures the name of the user who created the issue. Linked issues are a way to create dependencies between issues, such as one is blocked by another. The assignee is used to assign an issue to a specific user. Priority, self-explanatory and label is used to tag the issue with a free form text. Epic LOINC is used to associate the issue with an epic. It is already populated, not editable. Since we initiated the creation of the issue from the specific epic, we will ignore their Springfield for now and discuss it later in the lesson about spirits. Quick Create and the story comes up in the backlog. You can see here that it includes the epic label showing two which epic the story belongs to. Another option for creating an issue is using the create button in the top navigation. This button is available on almost all Jira screens. If you want to avoid navigating screens while looking for a specific epic, this button will certainly provide a faster way to create issues. Click on it and again, the Create Issue screen comes up. Make sure that story is the selected issue type and enter login in the issue of summary. The following fields are the same as when you created the issue from the epics panel, except that the epic field is now editable. And you should click on it and find and select Account Management epic, depending on your provisions in the epics listed this field, jira will show you epics from other projects. It is debatable if that is a useful feature or not, but that is the way it is. Once done, click on the Create button at the story comes up on the board. The third option for creating a new issue is useful if you want to create it quickly and don't need to populate any fields except the issues name. Here is how it is done. Look forward, create the issue link at the bottom of the backlog. Click on it, and the field for inline editing opens up. You can select the shoe type and you can enter its name. If you want to add any other information, you would have to edit the issue after creating it. Let's use this option to create one of our tasks. Select task from issue type drop-down, and enter performers alerting in the summary field and hit Enter. The issue is created and what backlog refreshes. You can click on the issue and edit other fields. We need to link this task to the alerting epic. So look for the epic link field and select alerting epic in it. Notice that different icons distinguished between issue types. Purple for an epic, green for a story, and blue for a task. Also, each issue has a unique identifier, prefix TS, which is our project key, followed by the issue number. The same set of steps I followed for the first three issues applies to creating any issue. There are quite a few more issues to create. But as I just explained, it is quite repetitive. So I will stop the recording while I do that. If you're following along, you should stop the video and create the remaining issues before continuing with the lesson. Now, we have all our issues in JIRA and notice they're all sitting in the backlog. The backlog is an essential concept in JIRA and agile. It contains all issues still waiting to be processed, meaning no work has been done yet on them. However, we still did not prioritize issues and we did not estimate the effort to complete them. In the next section, we will dive into the backlog management, the details, and we will grow our backlog. 14. Prioritizing Backlog: Backlog is one of the key concepts in Scrum and several other agile methodologies. I mentioned backlog in the lesson about Scrum. It I explained it as a place that contains all work that still needs to be done and has not started yet. I also noted the importance of maintaining a group backlog. Groomed means that all issues in the backlog are always sorted by priority, having the most important ones at the top of the backlog, at the least important to unsettle bottom. Therefore, the backlog is not just a dump site for the pending work or a place to shower ideas that you'll never be addressed. A good, clean, and well-maintained backlog is a critical success factor for any project. With that in mind, let's see how that applies to our course project. In the previous lesson, we have created all epics, stories, and tasks that we have identified so far. That gives us the backlog that properly reflects the project scope. But it still does not provide any information about priorities. Like of defined priority means that we still don't have a well-groomed backlog. We will start with the Epics. A reminder that in the backlog screen, epics are located in the epics panel on the left-hand side of the screen. I want to have searching products and viewing products worked on first, since a lot of other work depends on them. To place them at the top of the epics least, I will just drag them at the top of the list. They will be followed by account management and shopping cart management. After those, purchase management and the wishlist management will be taken care of. Epics, look good. It we could move on to stories and tasks. You might have assumed that setting epics priorities, we will reflect on their stories and that's searching products stories. We'll end up at the top of the backlog. Well, that is not the case and epic priority does not automatically impacted the priorities of the stories. There is a valid reason for that. Each issue within an epic has a different priority. If one epic has a higher priority than another, it does not imply that all stories from that topic have higher priorities than all stories from the other epic. In our case, I want to assign search products by category, the top priority. But I don't think that search product by price is more important than the product details. The bottom line is that epics relative priorities are directional and do not map one-to-one, two stories priorities. Knowing that, let's finally establish the priorities of our stories and tasks. I just mentioned that I want to give search products by category top priority. Of course, one option is dragging that story to the top of the backlog. But there is a quicker way to move a ticket to the top or the bottom. Right-click on that ticket, opens a pop-up with options to send a ticket to the top of the backlog or to the bottom of the backlog. One-click and search products by category becomes the top priority ticket. The next priority is the product details ticket. As it is a prerequisite for shopping cart and payments stories. I will drag the ticket, it place it right below the searching products by category. For the sake of time, I will not go through the reasoning for each tickets priority. It is very specific to each project. It can be fairly subjective. Attached to this lesson resources is the document with a fully prioritized backlog. You should stop the video, download it, and use it as a reference to complete the prioritization of your backlog. While I stop the recording and do the same on my end. Once you're done, you can resume the video. Having a prioritized backlog is a major milestone and we made it there. Before. We can start planning our sprints, we have to estimate the effort to complete each issue, and we will do that in the next lesson. 15. Estimating Work In Backlog: Estimating effort is probably a topic that creates the most contention in any Agile framework. There are plenty of techniques and approaches to estimating at the fully dedicated courses needed to cover it all. Therefore, we will cover the basics here just enough to be able to demonstrate how to capture and use effort estimates. It JIRA. If the work that needs to be estimated is never done before. And most of the time is software development. That is the case. It is hard to know exactly how much effort is required to complete the work. Teams spent endless hours debating and splitting hairs. If a task a little take two days or three days of effort. And if task B, we'll take eight days or nine days of effort. But the essence of the contention is the term exactly. According to Agile principles, we don't need to know exactly what the effort is. It is okay to establish the approximate effort. So if we rephrase the question to the team estimating the work as is the effort to complete task a two to three days? Or is it eight to nine days? We will quickly get an answer. That is precisely the reason why estimation using the Fibonacci sequence is popular and effective. In essence, quantitative expression of effort must be one of the numbers from the serious 1, 2, 3, 5, 8, 13, 21. Each number can represent days. Or for more mature themes, those could be storypoints. Regardless, the logic behind the methodology is that teams should pick a value that they think most probably represents the effort. In general, it is easier to understand the smaller tasks, which is why options 1, 2, and 3 exists. And as we move to more significant efforts, it is harder to come up with a number, but it is much easier to choose between few numbers. The one that is closer to the real effort, 8 or 13, or 21. There are no options in between. In our case, let's say that team did an estimation session and the outcome is captured in the document attached to the lesson resources. Each issue is assigned a number that represents the effort estimate. The auditor's, we will use it to enter estimates in JIRA. Go to the backlog screen if you're not already there. We will start from the top of the backlog. So click on Create Account story issue panel. We'll open up on the right-hand side of the screen. Look for the story points field and enter three. Keep going down the list and click on Login story. Find the story points field, and enter two. See, however, the estimates show up in the backlog besides each issue. But we might have a problem. Notice that there is no placeholder for the estimate field for our four tasks. And if I open the issue panel for any of these tasks, there is no story points field, quick disclaimer, this is the behavior of the default Jira configuration. If you're using an instance that had some level of customization, story Points field will be, might be present. So we establish that this is happening because the default Jira configuration does not include the story points field in the task issue type. However, we need that field to capture the estimated effort for these four tasks and use it when planning our sprints. We often said How extremely configurable gyrase. So let's see how that helps us in this situation. Basically, we need to add the story points field to the task issue type. To do that, admin permissions are required. If you have them follow along. And if not, it is still okay. Just watch and stay aware of how it is done. Go to the Settings menu by clicking on the little gear icon in the top right corner. And select issues. Look for custom fields in the site navigation. Click on it and search for the story points field with the screen loads. Opened the Actions menu on the right and select the context and the default value option. Notice that the story points field is associated only with epic story type issues. We want to add task type to this group. So click on Edit configuration. And while holding the Command or Control key, select task from the issue types list, make sure that story at the epic types remains selected. We want to discipline globally to all projects. So we will leave the global context options selected and click on modify button at the top, at the bottom to commit the changes. The task should show up besides story and epic types. And you can navigate back to the top store project. We are now ready to continue adding estimates to issues in the backlog. Let's update one of the tasks to verify the configuration change. We just did recall the performance monitoring task. Look for storypoints field, click on it, and enter two. We need to keep doing this for the remaining tasks using the Tao of the document for reference. Stop the video and complete this in your project. While I stop the recording and complete it in my project. Once you're done, you can resume the video. Now, we have one well-groomed backlog. All issues are sorted by priority and each issue as effort estimates. We are ready to start planning our sprints, and we will do that in the next lesson. 16. Creating Sprints: Now we have everything we need to plan our sprints. We discussed sprints in the Scrum lesson, which was quite a few lessons back. Let's have a quick recap on key aspects of the Sprint. A Sprint is a defined period of time, usually two to three weeks, during which a specified Chaco work will be completed. During a single sprint, a team will work only on the plant set of stories. Nothing more, nothing less. The expectation is that all stories included in a specific sprint will be fully completed by the spring tent. The third statement here is the most important one to keep in mind when planning sprints. So let's analyze it for a moment to make it more likely that all planned work is fully completed within a sprint, we must not plan more than a team can do. To be honest, we can plan the way less than a team can do and all plant work will be completed. But that would be unlikely regarded as an accomplishment. So our task when planning sprints, is to help our team do as much work as they can, but at the same time not plan for more than that. With that in mind, there is a very simple math that we can use to determine how much work our team can handle and which issues goes into which sprint. Let's say our team has to developers. And we will be running two weeks sprints during our project. In each two weeks sprint, there are ten working days. That means that each developer can do ten days worth of work in a single sprint. But we know that unexpected things can and will happen all the time. Company meetings, personal days of sick days, who knows what else? If we assume that unplanned events on average take away 20 percent of someone's effectiveness. That leaves us with eight days of effective work that each developer can do in a single sprint, that 20 percent factor is not made up. It is a widely recognized industry standard in project management. Once we establish those metrics, we can, with decent confidence, claim that two developers can do twice as much in a single sprint. So to developers times eight days worth of work equals 16 days worth of work. By doing this calculation, we establish the capacity of our team. Capacity is defined as the amount that something can produce. In our case, about is 16 days of work and something is our team in a single sprint. This moment is where we should appreciate the effort estimates we created in a previous lesson. For each issue in our backlog, we know the effort days required to complete it. We also note that the maximum effort of our team can complete in a sprint is 60 days. Therefore, where the place issues from backlog Sprints, we should ensure that the sum of estimates for all issues in a single sprint is not more than 16. That is not straightforward and require some juggling. But jira will make it much easier than if we're doing it in some other way. Let's see how it goes. Before creating our sprints. Let's figure out how many sprints we need to complete all work in the backlog. Again, we can quickly answer that question with a bit of math. Adding together estimates for all issues results in the total of 111 days of effort. Knowing that we can do 60 days of effort in each sprint, the total number of needed sprints is 111 divided by 16, which is 6.9. We can have fractional springs, so we will round up to seven sprints to complete the project. Next, we should establish a sprint naming convention. The first thing that comes to mind is naming the Sprint 1 and Sprint 2 and so on. But that is actually not the best practice. And here's why. During the Scrum project, there is a considerable number of references made to particular springs. For example, in which spring is logging story being worked on or for which sprint two, we need wishlist designs. The answers could be Sprint 2 and Sprint 4, but numbers are easy to mix up. So to avoid Sprint 3 becoming a wrong answer to both questions, we should avoid using numbers or any sequences in sprint names. It is common to use general knowledge items such as geographical terms. For example, names of cities or rivers, or names of movies. Anything that does not have sequences in it. For our project, we're going to use carbons. Our Seven Springs will be named Buick, Acura, dodge, whom they link called Tesla, Honda. Finally, we have everything we need to create sprints. To create a sprint, go to the backlog screen. At the top of the backlog least, there is the Create Sprint button. Click on it and sprint will be created and given a default name, Ts Sprint 1. We said that we would name this Buick. So click on the sprint Actions button on the right. Select Edit and change springs name to Buick. Click on the Update button and hours per sprint is created. I'm going to do the same steps to create Oculus print, Create Sprint, sprint, change the name to Acura update. And now I can see our first two springs in the backlog. They are empty and that is okay. Shortly we will assign issues to strings. We still have five more sprints to create. I'll go stop the recording while I'm doing that. And you should also pause the video and make sure that you created all seven sprints before resuming the lesson. 17. Planning Sprints: We have created our seven sprints and we can start planning them. Earlier. Reconfirm that our backlog groomed and the most important stories are at the top. But planning is not as simple as sequentially moving stories from the top of the backlog into sprints. We need to accommodate for dependencies between stories and the total effort of all stories in a sprint cannot go over 16. With that in mind, there is a problem right away. Total effort or the first two stories in the backlog is 18. So they cannot go together in the same Sprint. I will opt to go with product details because more stories depend on it. For example, adding to shopping cart and adding to officially stories can start without your product details. To add new product details to a sprint, I would right-click on it. And from the pop-up, I will select the sprint I want to send it to. In this case, it is during sprint. And the story is placed in the sprint. But also, I don't want to leave unused capacity in a sprint. I have a budget of 16 days to use and I have 13 days of effort assigned to BYU experience so far. So I want to find a story having an effort of three to maximize utilization of the sprint. Looking down the backlog, there is the create account story, which is a three-day for tissue. Exactly the size to perfectly feel the sprint, right-click and assign it to Buick sprint. Scroll up to find the BYU explained in both stories. You'll be there. Just below them. On the right side, you will see the total effort of issues assigned to the sprint. In this case, as expected, it is 16. We can move on to planning the next sprint, the accurate sprint. The natural choice of the first issue to add to this sprint would be the one that we decided not to add to the view experience even though it was at the top of the backlog, searching product by category. However, many stories depend on adding a product to the shopping cart and viewing the shopping cart. While these two depends on the login story, those are the reasons why they are ranked so high the backlog. Therefore, I will ignore searching by category one more time and add those three stories to the accurate sprint. Again, it is as simple as right-clicking and selecting the sprint. Same for product 2, shopping cart and for view shopping cart content. Let's check how much of the sprint capacity we have used. Jury says 13. 13 is used, so we have another three to allocate. Looking down the backlog for the next three sides story, ad product to wishlist pops up. So let's add it to accurate sprint. And our first two sprints are fully plant. You just learned how to plan springs and how to assign issues to strings. For the sake of time, I will stop the recording while I place the remaining issues in springs, and I will end the lesson. Before starting the next lesson, you should download the final sprint plan from the lessons resources and accordingly assign all remaining issues two sprints. In the next lesson, you will learn how to assign issues to GO users, how to start a sprint, and how to monitor the progress of a sprint. 18. Starting Monitoring And Closing Sprint: We have to do one more thing before we can start our first sprint. The sprint, we have to assign issues to members of our team. We have duty members, Jenny at Johnny, and let's see how we can split the work between them. A quick digression. If you already have any to users in your JIRA instance, you could use them in this lesson. If not, you can add users by going to the settings menu and selecting user management. Once the user screen, you can invite a couple of users to create their accounts. If that is too much trouble, dot worry about it. You can assign all the work to yourself. The objective of these exercises is to make you familiar with Jira screens, not to have a 100 percent tightly plan project. We have two stories in the BYU experience, but one is 13 days of effort and the other is just three days. We have established that each developer can do eight days of work in a single sprint. Johnny can take on eight days and Jenny can take on eight days. If we just assign view product details to Johnny and create account to Jenny, it is not balanced at Johnny will not complete his work while January we'll be left with extra not utilized time. We want to avoid either of the two. And the solution is quite simple. Jenny, we'll work on Create Account right from the beginning of the sprint. And she should have five days spirit after she's done. At the same time. Johnny is five days short or the time required to complete your product details. So Janice, five-day surplus is precisely what is needed to balance the books. After she's done with her story, she will help Johnny complete his story at both stories should be done by the end of the sprint. This match of numbers is not a coincidence. Remember when we established that 60 days of work is our team's capacity counted for both Jenny and Johnny? Equally dividing full stories between team members rarely happens when there are big stories in the backlog. But the premise for Scrum planning is that the, the works as one unit and team members will help each other have the work completed. That is why having a story assigned to someone does not mean that that is the only team member who will be working on the story. It only determines the person responsible for the story, but it does not preclude others from working on it. The theory will handle the micromanagement of the story in the sprint planning and daily stand-ups. However, we are starting to go deep into the Scrum process. Let's just decide your product details to Johnny and create the account to Jenny and go on to do that. Click on the issue and the issue panel on the right. Look for the assignee field and select the user to whom the issue is being assigned. In this case, Jony, do the same thing with the other issue at hepatocyte to Jenny. As issues are assigned to their owners. They would take another look into the issue details collected so far, and they will speak up to resolve any ambiguities. For example, when we created our stories, we did not provide any details. Now, just before starting the sprint is the last opportunity to do so. And after hearing concerns from Johnny and Jenny, we will add details in the description field of these two stories. The theme confirms that the newly provided details do not affect the current effort estimate. And we're good to go. Great. Now we can start the sprint. To do that, click on the Start Sprint button next to the sprint name. The popup comes where you can optionally change this breadth name and set the spring length, which defaults to two weeks, change the sprint start date and the described the sprint goal. I will only change the default length or the sprint, and I will make it three days. Of course, you would never help spread the short in a real project. This is just to help us go faster through all motions of Sprint progression. Leave other fields with default values and click Start. Sprint has started and we are transferred to the active sprint screen where we can monitor and update the sprints progress. We see our two stories sitting in a to-do to-do status and we can tell who they are assigned to when the work starts on them. They get moved into the in-progress status by a simple drag into the in-progress column. And they sit there while the work is progressing. Inevitably, questions will arise while the work is progressing, and when that happens, they will be posted in a comments section of each issue. Let's say I'm not clear which currency should be used when showing the product price. And I will post that question as a comment in the view product details story. As the spring progresses, the reveal lot of activity on all issues included in the sprint. All of that is captured in the issue's history tab. And you can always refer to it when you need to look back in the past. I can see here, when was the effort estimate created and who did it? When the issue was assigned to the sprint and many more also generally will do its best to inform all interested parties about any changes or activity in an issue. If you have created an issue or one has been assigned to you, you will receive a notification email similar to this each time when something is modified on the issue. Eventually, Jenny, we'll complete her story and move it to the Done status. Then she will help Johnny with the big story he owns at together they will work on this story to complete it by the end of the sprint. When finished, your product details, you'll move to TN status and that will complete all the work into BYU explained. Close to the end of the sprint. We should make preparations for starting the next sprint. We need to assign issues to their owners and resolve any ambiguities in requirements. Let's have a look. In the accurate sprint. We don't have any stories that are larger than the sprint. So dividing stories between our developers, you'll be more straightforward. View shopping cart content is estimated at eight days, so we can assign it to any and it will consume all her capacity. The total effort to complete the remaining stories is also eight days. So Jony should complete all of them. It all three are being assigned to him. Let's assume that after they reviewed stories, both Eddie and Johnny did not have any objections. That means that accurate sprint is ready to be started with. The time comes on the last day of the sprint. We will be closing the sprint by clicking on the complete Sprint button. The pop-up shows informing us how many issues have been completed in this sprint and what will happen with those not completed? Confirm your action at the sprint is closed. You are presented with a sprint report where you can see the breakdown of what was completed in this sprint and what was not. This particular report does not look very interesting as we hit only two stories at both were completed in the real Scrum projects when things don't go exactly as planned. The tibial lot of valuable information here that can be used to identify problems and come up with ways to fix them. With the Buick sprint completed, we are ready to start the accurate sprint. Click on the Start Sprint button. Use the same settings as the last time and start the accurate sprint. As expected. All false stories are in the to-do status. And as we looked at them, one potential risk pops out. The view shopping cart contents story cannot be completed without add product to shopping cart being completed first. Also, the latter one has to be completed well in advance to allow enough time for completion of view shopping cart content. So we want to ensure that the joining works first on Add product to shopping cart before starting any other work. And to take all steps needed to ensure that story is completed within the estimated effort, at least duration. To capture that priority JIRA, we will simply drag the story to the top of the stack of Sprint issues, which means we just established spring priority. To boost priority with more, I will set the priority attribute to the highest. As projects sprints progress, our project issues moved through different statuses. They belong to different screens and several people on them. We don't have a single view for all of them anymore. We also want to be able to view different groups of issues, such as only completed issues or only issues assigned to Jony, or only issue is larger than 30 days. In the next section you will learn about Jira filters, a powerful feature that you address everything I just mentioned. 19. Finding Issues: The number of projects and issues in JIRA Instance will continually increase. It will never go down. That is certain. Very quickly. It will become very time-consuming to find issues just by looking for them on different screens. Dura solves that problem with powerful search features. And in this section, you will learn how to use them. You can search for issues in JIRA on the project level and on the global level. We will review project level searching first. Let's say you want to find all issues in the backlog that have the wish-list in the title. Go to the backlog and in the backlog search box type wishlist. Notice that backlog issues are filtered out as you're typing. And at the end you will see only issues containing search terms. A similar search box exists in the active sprint screen, and it works exactly the same way. Both active sprint backlog have additional Greek theaters beside the search box. They allow for one-click filtering. For example, if you want to see only Jenny's stories, click on Janice avatar to remove the filter. Click one more time. You might have noticed another search box located in the toolbar at the top of the screen. That one is used for the global search and should be used to search for items across all Jira projects in the current instance, the moment you click on it, you will see many things in the results, even though you did not enter any search term yet, Jira gives you a list of recently viewed issues and recently visited boards, projects and filters. If that does not help find what you're looking for, you can enter a search term. If I enter login, I see a matching issue in our top store project, but I have another one in a different project, the roadmap project. On the right-hand side, there are multiple filters that you can engage as needed. For example, a project filter allows filtering results by any project. But the global search is not limited only to issues. It will also find other elements such as projects, boards, and filters. If I enter the search, their workflow returns results include two stories, one bug in one project that contain the word workflow in its name. This is all great for simple searches were looking for something by its name and perhaps a couple of additional predefined filters. But what if you need to find items based on other attributes? For example, all issues in the top store project that have estimated therefore larger than 8, or all issues across all projects assigned to a specific user. Jurors Advanced Search has a solution for that, and you will learn about it in the next lesson. 20. Advanced Search And Jira Filters: In the previous lesson, you learned about simple searches and you saw a few examples of the good things they can do. But there will be situations where they come short. Especially once you start using Jira to create custom reports or analyze different project metrics across various segments. Let's say you want to find the shoes from all Jira projects that are assigned to Johnny. You cannot do that with a simple search, while advanced search makes it very simple, you can get to the advanced search by following the link in the global search Dropdown. Click on it and you arrive at this screen. You are now actually the filter screen. And notice a long list of predefined filters, such as myopia issues or issues reported by me and many more. On the left-hand side. General filters are actually nothing else other than predefined searches. You can use any one of them and feel free to try them out. But let's now stay focused on our task to find all issues from all projects assigned to Johnny. In advanced search. That is accomplished by creating a query in something called Jake QL, which stands for JIRA Query Language. Learning. Jkl goes far above the scope of this course. You can find a lot of resources on the web if you want to get more proficiency in it without going into the details of JKL syntax, this is how you would use it. Click on the far left side in the query text box and start typing that query. We are looking for all issues where Johnny is assignee. So I will talk. Assignee equals Johnny. Notice how jurors giving me hints while I'm typing. To accept the hint, you can just click on it. Once the query looks OK, click on Search at the results. Come back. I see John is issues from the top store project, but there is also another one from a different project. I can tell that because it has a different prefix, the issue key. This is great, but if I plan to use this query, the future, I don't want to type the whole JKL each time. In that case, I can save this query as a permanent filter and run it without recreating it over and over again. Notice the same as link beside the search heading. Click on it and you will get the same filter pop-up. Give the new filter name, say John his work, and click on Submit. John is worth filter will now show in the filters list and you can run it with a simple click. The filter is already start and you can get to it quickly from the filters dropped out in the main navigation. 21. Course Roundup: Congratulations on completing this course. You went through a lot of content and now you are familiar with the fundamentals of Jira. You should feel confident to start using Jira for real projects. Here's a quick summary of what you achieved by going through this course. You have full access to JIRA in the Cloud. You are familiar with the core concepts and principles of Agile and Scrum. You understand the concept of Jira projects and know how to create one. You understand the concept of JIRA issues and the differences between basic tissue types. You went through the process of breaking project requirements down to JIRA issues. You created the issues in JIRA, you groom backlog your plan, then created sprints. You're familiar with the sprint management process and you'll learn how to look for specific issues in JIRA. That is a lot of stuff. So go ahead, start or continue working on your projects and use what you learned in this course to utilize JIRA to help you with your work. I hope that you like to course and found it useful. And if you did, I would really appreciate you taking few seconds to rake the course and help others interested in JIRA find it and enjoy it as you did all the best.