All right ...
let's do this. Hey! What is up awesome
people? Welcome back to my channel. For
those of you who are new to this channel,
welcome on board to the community of
passionate change makers. My name is
Joshua Partogi, I'm a Professional Scrum
Trainer based in Brisbane, Australia. I
hope you're having an awesome week folks.
So today I want to accomplish one of my
Goals for 2021, that is to ...
create a video that explains Scrum
based on Scrum Guide 2020 in under 7
minutes ...
but without cutting out the Scrum core
principles.
Hopefully I'm able to achieve it. So
without further ado let's do this. Scrum
is a lightweight framework that helps
people, teams and organizations generate
value through adaptive solutions for
complex problems.
Scrum is built upon empiricism where
knowledge comes from experience and
decision making is based on what is
observed. To put it simply, Scrum is not
about making assumptions, Scrum is about
validating assumptions. The three legs
of empiricism is transparency, inspection
and adaptation.
Secondly, Scrum is built upon simplicity
and lean thinking, where anything in the
whole value stream that does not add
value to the customers is considered as
waste and should be removed as it only
adds overhead and adds complexity.
Thirdly, Scrum is built upon
self-management and bottom-up collective
intelligence where people are viewed as
smart, reliable individuals and empowered
to make decisions on who does what, when
and how.
As a framework Scrum consists of three
accountabilities. These are
accountabilities ... not job titles.
Regardless of the person's job title in
the company ... whoever is accountable for
maximizing the value of the product
resulting from the work of the Scrum
team and also accountable for effective
Product Backlog management, in the
context of Scrum, this person is the
Product Owner. When there is one product,
there shall only be one Product Owner.
Regardless of the person's job title in
the company, whoever is accountable for
establishing Scrum as defined in the
Scrum Guide and accountable for the
Scrum team's effectiveness, in the
context of Scrum this person is the
Scrum Master. The Scrum Master is a true
leader who serves. And lastly, the people
who develop the product regardless of
their job title and their pay grade in
the company, are the developers. They are
accountable for creating a plan for the
Sprint, instilling quality into the
product is defined in the definition of
done, adapting plan each day toward
achieving the Sprint Goal, and holding
each other accountable as professionals.
Together, as one unit the Product Owner,
the Scrum Master and the developers are
the Scrum Team. The entire Scrum Team has
a shared accountability to create a
valuable useful increment every single
Sprint. For further explanation on the
accountabilities in Scrum, check out my
videos on Scrum Master, Product Owner and
developers on this channel, if you
haven't already watched it. The Scrum
team and everyone in the company who
interact with them live this Scrum
values because without living the Scrum
values, Scrum implementation in the
company will just be a mini-waterfall or
the
zombie Scrum.
If you haven't watched my video on
elaborative explanation on the Scrum
values check it out by clicking the link
up here. Besides the three
accountabilities, the Scrum framework
also consists of three artifacts with
its respective commitments and also five
events to enable empiricism. Let's see
how the accountabilities, the artifacts
and events work together and make up the
Scrum framework.
The Product Backlog is an emergent
ordered list of what is needed to
improve the product. It is one of the
artifacts of Scrum. Its commitment is the
Product Goal. The Product Backlog is
continuously refined to increase shared
understanding.
If you haven't watched my video on the
Product Backlog and the Product Goal, go
check out those two videos on this
channel.
Product Backlog is one of the inputs for
Sprint Planning. The Sprint Planning is
one of the events in Scrum. It's only
attended by the Scrum team. During Sprint
Planning, the Scrum Team has three main
agenda, create the Sprint Goal, select
items from the Product Backlog that can
fulfill that Sprint Goal and decompose
the selected Product Backlog items into
smaller work items for developing a
usable valuable increment. The result of
the Sprint Planning is the Sprint
Backlog with Sprint Goal as its
commitment. The Sprint Backlog is the
second artifact in Scrum. If you haven't
watched my video on Sprint Planning,
click the link up here for more details
on the mechanics and the other inputs
that should be inspected during every
Sprint Planning.
After the Sprint Planning, the developers
will work based on the Sprint Backlog
and also the Sprint Goal every day in 15
minutes or less. They will make a small
plan for achieving the Sprint Goal in an
event called the Daily Scrum. If the
Product Owner and the Scrum Master are
also involved in development, they also
join the Daily Scrum. During Daily Scrum,
the developers may discover the Sprint
Backlog needs to change or the scope may
be less than what they have planned
during Sprint Planning but as long as
the developers can still fulfill the
Sprint Goal everyone shall respect and
support their decision because the Scrum
Team is committed to the Sprint Goal not
to the Sprint Backlog. The problem
solving should be done after the Daily
Scrum this is to ensure the Daily Scrum
does not drag more than 15 minutes.
If you haven't watched my video on Daily
Scrum, click the link up here for more
details on the mechanics of Daily Scrum.
Before the end of the Sprint, there
should be a usable and valuable
increment otherwise the value of the
product and the progress towards
achieving the Product Goal cannot be
measured quantitatively. The increment
has a commitment to fulfill every
checkbox in the definition of done as
such the quality of the increment is at
a state where it can immediately be
released and used by the consumers. The
increment is the third artifact in Scrum
with definition of done as its
commitment.
If you haven't watched my video on
increment and definition of done go find
those two videos on this channel.
The increment is one of the inputs for
Sprint Review. The Sprint Review is
another event in Scrum. Besides the
increment, during the Sprint Review the
Scrum Team and anyone who has a stake or
has an interest with the product also
inspect the current market conditions,
any new opportunities, the remaining
budget and the progress towards the
Product Goal. The purpose of the Sprint
Review is to gather feedback so the
company can remain competitive in the
market. It's not for demoing the
increment or is a phase-gate approval
event. Any feedback that is given during
the Sprint Review goes to the Product
Backlog. It is up to the Product Owner to
decide when that feedback will be done
by the Scrum team.
The Product Owner's decision shall be
respected by everyone in the company.
If you haven't watched my video on
Sprint Review click the link up here for
an elaborative explanation and also myth
busting about Sprint Review.
After the Sprint Review, the Scrum team
will hold the fourth event in Scrum
called the Sprint Retrospectives to plan
ways to increase the overall product's
quality and their effectiveness as a
team. Actionable improvements as the
result of the Retrospectives may be
added to the next Sprint Backlog. After
the Retrospective ends, the next Sprint
Planning will immediately start on the
following day. So all of these here are
wrapped in a container event called the
Sprint.
When the Sprint Planning starts the
Sprint starts, when the Sprint
Retrospectives ends the Sprint ends. All
of the five Scrum events are time boxed
to increase focus and to maintain rhythm.
We shall not view the Sprint as a mini
waterfall. Instead view it as a cadence
for planning and pivoting. In Scrum, the
Scrum team is empowered to release the
increments to the production
environments multiple times in a Sprint.
So that is the Scrum framework folks. It
is a bare minimum framework to enable
empiricism and it is intentionally
designed to be simple and incomplete to
give room for us to customize it to our
contexts. To solve a complex problem we
need a simple framework. Everything else
that is not defined in Scrum guide such
as user story, velocity, burn down chart,
planning poker, kanban, devops, user
experience, design thinking, nexus,
evidence-based management metrics, and
even Objective Key Results or OKR are
considered as complementary practices. It
can be used with Scrum but it's not part
of Scrum. It is left up to the Scrum team
to decide which complementary practices
they should use with Scrum. Click the
link up here to see videos on some
complementary practices for Scrum that
are already available on this channel.
That is all from me today folks.
Thank you,
thank you and thank you for watching
today's video. I hope you found today's
video valuable.
If you found it valuable, please share
today's video to your friends or your
colleagues at your workplace or even on
social media. Don't forget to do all of
those things that you need to do after
watching videos on youtube .. subscribe to
this channel if you haven't already,
click the like button down below and
watch other videos on this channel by
clicking the thumbnails here and also
down there.
See you until my next video folks until
then stay safe and don't forget to stay
awesome.