Scrum Refresher

A free video tutorial from Jimmy Mathew
Agile Coach, Trainer
Rating: 4.3 out of 5Instructor rating
32 courses
59,757 students
Scrum Refresher

Learn more from the full course

Scrum Tales: Scrum Training Through Real Life Scenarios

This course captures 6 such scenarios, stories from Scrum teams.

34:03 of on-demand video • Updated March 2024

This course captures 6 scenarios, stories from Scrum teams.
Experience Scrum with practical scenarios
Gain more confidence in facing scenario bases questions on scrum
Each scenario is analyzed within the Scrum Framework.
A new perspective, a better understanding of scrum in practice.
Includes bonus lecture with exclusive discounts for other courses.
Welcome back; here, we will have a quick visit to the Scrum framework. If you have good knowledge of Scrum, you can skip this section and move on to the next section. Let's start with the Scrum framework. Every software project is intended to convert a number of requirements into working software, an Increment, or a change. Scrum follows an iterative and Incremental approach. The work is carried out in multiple iterations called Sprints. Sprint is time -boxed to a maximum of one month. The purpose of Sprint is to create a potentially shippable Increment of working software. Before getting into the details of this process, let's discuss different roles defined in Scrum. Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment for each Sprint. They decide how they are going to create a shippable Increment at the end of the Sprint. They have all the skills required to convert the selected requirements into the "done" shippable Increment. The specific skills needed by the Developers vary with the domain of work. Developers are always accountable for Creating a plan for Sprint. This will be in the form of Sprint Backlog, which we will see later. They are accountable for the quality of the product. Every day they inspect and adapt their plan to maximize the chances of achieving the Sprint Goal. The Product Owner is responsible for maximizing the value of the product, resulting from the work of the team. He owns the requirements. This activity consists of detailing backlog items, ordering or prioritizing them to maximize the value, and clearly communicating them to the team. They develop and explicitly communicate a clear Product Goal. The Product Owner may delegate some of the Product Backlog management responsibilities to others. But the accountability remains with the Product Owner. The Scrum Master is a true leader, a facilitator, and a coach. The Scrum Master is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. He or She ensures that the Scrum is understood and enacted by the team. He or She facilitates the Scrum events as required. Scrum Master makes sure the impediments for the development are removed. The Product Owner, the Developers, and the Scrum Master, together referred to as the Scrum Team. The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically ten or fewer people. Product Backlog captures all the requirements needed to be included in the product. This is created and maintained by the Product Owner. The Product Backlog is an ordered list of everything that is known to be needed in the product. Sprint starts with a Sprint Planning meeting. This is time -boxed to 8 hours for one-month Sprints. For shorter Sprints, it is usually shorter. The Product Owner explains the Product Backlog items and explains the expectations. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. Developers select items for upcoming Sprint based on their capacity. Team velocity, the size of work that they have successfully delivered in the last Sprint, helps as a guideline while deciding their capacity for the next Sprint. In other words, what is going to be included in the Sprint is decided here? The team creates an initial plan for converting the selected items to a shippable Increment. This may be in the form of technical tasks for each selected item, or maybe only for items to start with. This explains how the team is going to achieve the Sprint Goal. The Sprint Goal, selected backlog items, with a plan for achieving it, make the Sprint Backlog. Developers own the Sprint Backlog and keep it updated throughout the Sprint. They start working on the selected backlog items towards creating the Increment to achieve the Sprint Goal. They do design, development, and testing all in the same Sprint. They will do whatever is required to achieve the Sprint Goal. Every day, Developers do a Daily Scrum meeting. This is of 15 minutes duration. This takes the form of a stand-up meeting, where they collaborate and decide on actions to be done before the next Daily Scrum. It is kind of quick daily planning. Normally, it takes a form where every member answer three questions. What have I done since the last daily scum for achieving the Sprint Goal? What am I going to do till the next Daily Scrum? Do I see any threats for the Sprint Goal? At the end of the Sprint, the Scrum team, and other stakeholders, as invited by the Product Owner, conduct a Sprint Review. This is time -boxed to 4 hours for one-month Sprints. For shorter Sprints, it is usually shorter. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is not just a status meeting. The presentation of the Increment is intended to elicit feedback and foster collaboration. The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. This is time -boxed to 3 hours for one-month Sprints. For shorter Sprints, it is usually shorter. There are different methods used for retrospectives. For example, the team may try to find out What went well, what didn't go well, what are areas of improvement. Both Sprint Review and Sprint Retrospective may have an outcome that impacts the next Sprint Planning. A new Sprint starts immediately after the previous Sprint ends; there is no gap in between. Scrum teams conduct Sprints one after the other, creating software Increments in an iterative and Incremental way. As mentioned before, the team create tested and shippable Increment at the end of each Sprint. It may get deployed as it is or waits for further Increments. However, the team will keep on producing shippable Increments. As we have already seen, there are 3 roles, 3 artifacts and 4 ceremonies in Scrum. The roles are Product Owner, Developers, and Scrum Master. The ceremonies are Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospectives. The artifacts are Product Backlog, Sprint Backlog, and the Increment.