Agile Concepts + Scrum Refresher

Kosh Sarkar
A free video tutorial from Kosh Sarkar
Product Manager
4.5 instructor rating • 2 courses • 49,748 students

Lecture description

This lecture goes into details of how the scrum methodology works, and touches on all the key points about this agile process.

Learn more from the full course

Learn JIRA with real-world examples (+Confluence bonus)

Learn to work on, manage & administer agile projects with this comprehensive course on JIRA Software & Confluence

11:16:33 of on-demand video • Updated May 2020

  • Understand what JIRA is, benefits of JIRA and how to use JIRA
  • Understand Scrum - the stakeholders, events and overall flow of work
  • Understand Kanban flow of work
  • Use JIRA as a user working within an agile team - creating, working on and searching for issues, customizing dashboards etc.
  • Use JIRA as a manager of an agile team - configuring agile boards, managing the backlog, sprints and releases etc.
  • Administer all aspects of JIRA - create users, groups, set permissions, configure issue types, screens, fields, workflows etc.
  • Use examples presented in this course to customize and use JIRA based on your own unique needs
  • Get ideas (through examples presented in the course) on how JIRA can be utilized for different scenarios or situations
  • Learn the basics of Confluence
  • Learn how you can use both JIRA and Confluence together to work better and be more productive in general
English Agile is a software development methodology that has an iterative approach to development, basically building and releasing software incrementally from the start of the project rather than trying to deliver everything all at once right at the end. This iterative approach involves planning a development iteration, implementing the work planned for that iteration and delivering a version of the product by the end of it. Feedback is then gathered and used to plan the next iteration. And this process continues until the product is fully polished. This process allows the team to adapt to changing requirements as the feedback loop starts at a very early stage. So if some requirements change because the iterations are relatively short, these changes can be fed into the next iteration thereby keeping the overall development flexible and adaptive and at the end of integration there should be a shippable product or group of features. This frequent delivery of the product results in customer satisfaction as they are able to monitor the progress of development and are able to test and provide feedback early on thereby ensuring that their requirements are met and the team is on track. The goal is to keep requirements and documentation lightweight and flexible and this can only be achieved by ensuring close collaboration between team members especially between business people and the developers. Now there are many agile methodology all of which follow these concepts to some extent. Jira supports two methodologies scrum and Kanban. Scrum is probably the most highly recognized agile methodology. It works by breaking projects down into smaller bits of user functionality represented by epics and user stories. An EPIC can be defined as a larger body of work or work that cannot be completed in a given iteration. And so it usually gets broken into multiple user stories. A user story or just story is basically the smallest unit of work and can represent a feature that has to be developed. If you look at this course as an example you could say that for the Jira course project this Jira and agile concept section is an epic and the individual stories within the Epic are each of the lectures within the section including this one. Stories are usually defined using a particular format by specifying the type of user involved what the user is trying to achieve and the benefit for achieving it. For example as a manager I would like to learn about Jira so that I can use it to manage projects using agile workflows. So once features for a project are gathered and corresponding user stories are defined, they are then prioritized and continuously implemented and delivered in short cycles known as Sprint's. So this is the basic flow of work with scrum. You start off with a product backlog that contains all the features you want to build in the form of user stories. These features or stories get prioritized. So the most important features are at the top of the backlog. Its also important that these features at the top of the backlog are in a ready state with all requirements and details laid out, which essentially means that it is ready for development. A group of features are then selected from the product backlog and made into the Sprint backlog. Basically representing that these features are what the team will implement during this sprint. A sprint is a predetermined length of time usually between two to four weeks where the development team takes the tickets from the Sprint backlog and gets them to a done state by the end of the sprint. And during this sprint the team has a daily 15 minute scrum meeting at the same place and time every day to discuss the progress of the Sprint and make sure that things are on track and by the end of the Sprint the teams should have a shippable group of features that can then be reviewed by customers or relevant stakeholders. Now when it comes to scrum there are a few roles with specific responsibilities. The product owner basically owns the product and defines the vision of the product. In other words he or she defines what should be built and why. As a result the product owner is responsible for defining what goes into the product backlog. He also creates the user stories prioritizes them and ensures they are groomed with all relevant details. The development team basically builds the product and is responsible for providing shippable features at the end of the Sprint and the scrum master facilitates the scrum process and basically makes sure the team is on track during a sprint and that there are no blockers on anyone that would prevent the Sprint goal from being achieved. During the scrum process there are a few events that are critical to being successful. The Sprint planning is where the Sprint backlog is created by selecting the fully groomed and highest priority features from the product backlog that the dev team can work on during the next sprint. The srum and team then goes ahead and provides their estimates for time and effort to implement the features and all of this happens during that Sprint planning meeting. Now quick note on estimation. You can either estimate in hours or story points. Story point estimation is basically done where estimates are made relative to the smallest component or item with the known level of difficulty. After a few sprints the team will know how many story points they can complete in a sprint. Also known as Team velocity so they can use this metric to predict how many story points they are going to be able to fit in the next. So once the Sprint planning meeting is complete and the sprint starts, a daily 15 minute scrum meeting is held with all the members of the team and mainly facilitated by the scrum master. This meeting is always limited to 15 minutes or at least should be limited to 15 minutes. So the team members usually stand up while doing it to ensure that it doesn't go any longer. During this meeting every team member gets a turn to talk about what the person did yesterday what the plans are for today and if there are any blockers. Now if there are blockers This is where the scrum master can step in and work with that team member to get things unblocked and moving again. So the stand up scrum meeting occurs every day of the Sprint and at the end of the Sprint there is a sprint review and retrospective meeting. The review part of the meeting basically entails reviewing the features or stories that were completed or not completed and working with the product owner on shipping the completed features if required. The retrospective part of the meeting is to simply reflect on the last sprint and talk about potential to improve the overall process. Now what happens during a sprint. The team can monitor and update the progress of work through a sprint board or scrum board and this board is one of the major features available on Jira. In fact this image is an example of a scrum board from Jira. A scrum board is typically structured in the form of columns and the goal of the Sprint is to basically move all the tickets from the left most column to the right. You may have seen physical scrum boards being created in offices where they would use a whiteboard board draw the columns on there and use sticky notes to represent the user stories and manually move the sticky notes from one column to another. Fortunately Jira digitizes all of that for us. This example shows the most basic board where at the start of the Sprint, the to-do column basically represents the Sprint backlog. And developers would start working on tickets and move them to the in-progress column. And once implementation is complete they are moved to the done column. The goal of the Sprint obviously is to have all tickets in the done column. This board can also look different for every team. So some teams may want to have more statuses or columns. For example tickets that are in progress when complete will go to a code review column and then once code review is complete it will then go into a testing column before it finally gets to the done column and some of this customization is possible in Jira and is actually something that we'll be doing later on in this course. So every team can change the board and add columns to represent their unique workflow steps and Jira allows you to do this very well. So to summarize scrum, the product owner creates and manages the product backlog by filling it with PBI's or product backlog items also known as user stories which can represent a feature to be developed. A sprint planning meeting is then held with the entire team including developers where the highest priority stories which are usually at the top of the backlog are put into the Sprint backlog during this process. The developers also provide an estimate of effort for each of the stories. The sprint then begins and every day there is a 15 minute stand up meeting to discuss the progress of the Sprint. The scrum master facilitates this and ensures the team is on track and unblocked and at the end of the Sprint review and retrospective meeting is held with all team members and the product owner works with the team to package the completed features into a potentially shippable product. This is basically the essence of scrum workflow.