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.
33:54 of on-demand video • Updated January 2025
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.
English
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.