In this video, we will discuss an overview of Scrum and discuss scrum artifacts. We will start by discussing scrum in general. According to the Scrum Guide, which is written by the creators of scrum. Scrum is a framework for developing, delivering, and sustaining complex projects. It is a relatively simple framework for dealing with complex, unpredictable projects. By framework, we mean that scrum contains basic structures and ideas for completing a project. The scrum guide refers to scrum as a process framework for your project management and work techniques rather than a standalone process or definitive method. So the basic ideas of Scrum can be customized to suit your specific project. This is in contrast to a rigid methodology in which every project is executed the same way. Much of what we discussed in this video is discussed in the Scrum Guide. It is free, relatively short, and very well-written. It's highly recommended that you read it. Scrum is a way of achieving the idea of agility. In the previous videos, we have seen that Kanban is another option. You can think of agile as a mindset and the methods and frameworks such as Kanban, Scrum, and XP as ways of achieving agility. A key component of scrum and agile in general is continuous learning. Scrum projects start with a vision. This is the initial desired end result of the project. The stronger the vision at the start of the project, the better. The product is then work done and iteration at a time. After the first iteration, we have some of the features of the product. Even though the product only has a few features, it can be considered usable with respect to those features. That product should have value and potentially can be given to the customer. After the first iteration, notice that our vision has slightly changed. This is because we have learned from implementing the first product features and adapted our vision accordingly. After our second iteration, the product contains the work of the first iteration as well as the work of the second iteration. It now has more features that the customer will value. Because of continuous feedback, we may have improved some of the features from the first iteration. Notice that our vision has again been adapted. After the third iteration, our product is closer to our vision, but our vision has again changed slightly. You can see that we are building the project incrementally because we are building it piece by piece. We are building it iteratively because the product gets improved as we are learning along the way. That is why Scrum is both an incremental and iterative approach to building projects. This process of building and improving parts of the product continues indefinitely, allowing the product to stay relevant in a changing marketplace. If the product that is being built has a physical aspect, such as a rocket, the result of an iteration may be a prototype rather than a part of a completed product. At the end of every iteration, a product called an increment is ready. Here we see that three iterations have created three increments of the product. An increment is a usable product that may be given to the customer. The organization always has the option to release the increment. Each increment must meet the organization's agreed upon definition of done. This includes quality and security standards, as well as other organizational requirements, such as requiring documentation for each feature. Each increment contains the work of the current iteration as well as the work of all prior iterations. In other words, an increment is the complete state of the product after an iteration. In scrum, iterations are called sprints. A sprint is a time-boxed to period used to work on an increment. The time period of a sprint is fixed. In general, you do not shorten or lengthen the duration of the current sprint. Sprints usually have a duration of 1-4 weeks, with two-week sprints being typical. Shorter sprints create an opportunity for more adaptation. Longer sprints allow for more work to be done in a single increment. It's up to each team to decide on the appropriate sprint length. There are three main parts of the scrum framework. Artifacts are tools that allow for transparency of the project. They allow anyone with access to them to see the current state of the project. The artifacts that we will talk about in this video are the product backlog, the sprint backlog, the sprint goal, the sprint board and the sprint reports. The second part of the Scrum framework are the roles related to scrum. In the next video, we will discuss the roles of product owner, scrum master, development team members and stakeholders. The third main part of the Scrum framework are the events related to scrum. These are also called ceremonies or meetings. The sprint guide considers the sprint as a container event for other events. In the next video, we will discuss the sprint planning meeting, daily standups, the sprint review and sprint retrospective. Next, we will discuss scrum artifacts. In this video, we will discuss the scrum artifacts shown here. The main purpose of the artifacts is to provide project transparency. Anyone with proper access can use the artifacts to see the current state of the project, including the project's history and future plans. This enables the team to have a shared understanding of the project so that everybody is on the same page. The scrum artifacts are used to enable inspection and adaptation both inside and outside of scrum meetings. A product backlog is an ordered, ever-changing to do list for the project. It contains issues that are not yet part of any sprint. The scrum guide refers to issues as items. You might also hear them referred to as stories. Constant feedback means that the product backlog is always changing. Here you can see the product backlog in Jira. It's located under the backlog tab for scrum projects. This product backlog contains three issues. When you first add issues to a scrum project, they are automatically placed in your product backlog. The product backlog can include issues that represent features, improvements, bug fixes or any other type of issue that you would like. The product backlog is ordered. Issues near the top of the backlog are the closest to being worked on, so they usually have more details than the lower items. Modifying the product backlog is called product backlog refinement. You might also hear this referred to as backlog grooming. According to the scrum guide, each scrum team decides how to do refinement, but it should consume no more than 10 percent of the development team's time. In Jira when you are ready to plan a sprint, you navigate to the product backlog and click the "Create Sprint" button. After clicking the Create Sprint button, Jira creates an empty sprint. You can see here that Jira named the sprint using the project key, which is PRJ in this example, and the sprint member which is one in our case. You can see that Jira invites you to drag issues from your product backlog into the sprint. Here we have dragged two of the issues from the product backlog to the sprint. The list of issues to be completed during the sprint is called the sprint backlog. The sprint backlog includes a plan on how to accomplish the work of the issues. In Jira, this means that before starting the actual sprint, more details are added to the issues in the sprint backlog. Those details describe how the work of the issues will be done. As part of planning for sprints, it is common to estimate how much work an issue will take. Story points are the most common estimation statistic. In Jira you can use story points, hours, issue count or create your own estimation statistic. Story points are a relative measure of the amount of work required to complete an issue. For example, an issue that is assigned two story points is assumed to take about twice as long to complete as an issue that is assigned one story point. You can see that in Jira, there's a field on each issue named story points. In the sprint backlog, you can see that the story points are shown in the gray boxes along with a total estimate of three points for the sprint backlog. Story points are used to help the team decide how many issues can be completed in a sprint. When you want to start a sprint, you click the "Start Sprint" button associated with the sprint. The start sprint screen appears. Jira starts by reminding you that you have added two issues to the sprint backlog. You can modify the sprint name, specify the sprint's duration, and specify the start date for this sprint. You can see that you can have the sprints started at a later date, so you don't have to actually click the start sprint button on the first morning of the sprint. You could also set up multiple sprints at one time. The start sprint window also contains a place to enter what is called the sprint goal. The sprint goal represents the objective of the sprints increments. The sprint goal is reached by completing the issues in the sprint backlog. A scrum role is that the sprint goal does not change during the sprint. The sprint is considered a success if the sprint goal is reached. There are two major reasons to have a Sprint Goal. The first is that it provides a coherence to the product increment. This means that the features are related so that the product increment is valuable rather than building a collection of unrelated features. This also results in the Scrumteam working together to achieve the Sprint Goal. The second reason is that it enables flexibility with the sprint backlog. Projects are complex and even though the sprint duration is relatively short, the team cannot predict the future and will learn and adjust during the sprint. There has to be flexibility somewhere. The sprint goal remains fixed during the sprint, but the issues that achieve the sprint goal can be modified as long as quality is not decreased. This means that there's flexibility in the makeup of the sprint backlog as the sprint is worked on. The sprint goal provides guidance for decisions as the team makes adjustments. A sprint has a sprint board. Notice that it only contains the issues in the sprint backlog. Issues in the product backlog or issues that are assigned to other sprints are not shown on the sprint board. Even in sprint projects, boards are often called Kanban boards, so don't be confused if you hear that term related to a sprint. We have seen in an earlier video the importance of reports in agile. They are tool to visualize the work, promote transparency, help with troubleshooting and continuous improvement, and help with planning and estimating. In Jira, you access reports using the Reports tab in the sidebar. You can see that Jira automatically provides many reports related to your project. Scrum has some common reports related to sprints. We will discuss the Burndown chart, spring report, and velocity chart. A Burndown chart shows the progress that the team makes during a sprint. The sprint backlog starts with a certain number of issues, each with an associated number of story points or other estimation statistic. The total number of starting points is shown on the left of the chart. This is the number of story points that the development team estimated that it would complete in the sprint. In our case, this sprint has three story points. The gray guideline shown is used to show the number of story points that should remain on a given day, assuming a linear Burndown of story points. On the last day of the sprint, the guideline reaches zero story points. This means that the work of the sprint should be finished on the last day. Notice that the non-working days are shown in the chart and the guidelines assume no progress will be made on those days. As the sprint is underway, Jira will automatically update the Burndown chart as the status of the issues are updated by the team. The red line shows the actual number of remaining story points over time. You can see that about two days into the sprint, one story point was completed. On the last day of the sprint the remaining two story points were completed. Consulting this chart is an easy way to see if the team is on track for the current sprint. If the red line is below the gray line, your team is on track to complete all of the story points and reach the sprint goal. If not, the team may need to make some adjustments to reach the sprint goal. The link shown contains more information on Burndown charts. The sprint report contains a nice summary of the sprint. It shows the Burndown chart as well as the current status of all of the issues in the sprint. This is an easy way to see how the sprint is progressing. Velocity represents the rate at which the team accomplishes work. Usually it is the number of story points completed per sprint. Some teams use an estimation statistics other than story points, so in that case, velocity measures some other units completed per sprint. You can see the team's velocity of a single sprint by looking at the Burndown chart. In this sprint, the team completed three story points so its velocity is three. The velocity chart shows the estimated and the actual velocity of the team over time. In this example, prior to the first sprint, the team estimated that it would complete 13 story points shown with a gray bar. It actually completed those 13 story points as shown by the green bar. The velocity of the team for sprint one was 13 story points. In sprint two, the team optimistically estimated that it could complete 15 story points. It actually completed 10. The velocity chart shows a quick snapshot of the changes in the team's productivity over time. Here's a review of what we've discussed in this video. Scrum is an agile framework. An increment is a potentially shippable portion of the project that meets the "definition of done". A sprint is a time boxed period in which the increment is created. Scrum artifacts provide project transparency, enable shared understanding, and enable inspection and adaptation. Artifacts include the product backlog, the sprint backlog, the sprint goal, sprint boards and reports. Velocity is the rate at which the team accomplishes work, usually in story points per sprint.
