Scrum is an agile process that focuses on delivering business value in the shortest time. It delivers working software in short iterations called sprints. The key aspects of scrum include user stories to define requirements, a product backlog to track and prioritize work, sprint planning and daily standups to coordinate work within a sprint, and sprint reviews and retrospectives after each sprint to inspect progress and improve processes. The scrum team consists of a product owner, development team, and scrum master. The product owner manages the product backlog. The development team does the work. And the scrum master facilitates scrum processes and removes impediments.

2. Scrum Process

3. Agile is a continuous iteration of development and testing in the software development process
whereas Scrum is an Agile process to focus on delivering the business value in the shortest time. Agile
methodology delivers the software on a regular basis for feedback while Scrum delivers the software after
each sprint.
What is
Scrum

4. The Three Pillars of Emprircism
(Scrum)
Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements
an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places
great emphasis on mind-set and cultural shift to achieve business and organizational Agility.
•Transparency: This means presenting the facts as is. All people involved—the customer, the CEO, individual contributors—are transparent in their day-to-day
dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and
collectively collaborates for the common organizational objective, and no one has any hidden agenda.
•
Inspection: Inspection in this context is not an inspection by an inspector or an auditor but an inspection by every- one on the Scrum Team. The inspection can
be done for the product, processes, people aspects, practices, and continuous improvements. For example, the team openly and transparently shows the
product at the end of each Sprint to the customer in order to gather valuable feedback. If the customer changes the requirements during inspection, the team
does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypothesis.
•
Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone in the organization
must ask this question regularly: Are we better off than yesterday? For profit-based organizations, the value is represented in terms of profit. The adaptation
should eventually relay back to one of the reasons for adapting Agile—for example, faster time to market, increased return on investment through value- based
delivery, reduced total cost of ownership through enhanced software quality, and improved customer and employee satisfaction.
Scrum works not because it has three roles, five events, and three artifacts but because it adheres to the underlying Agile principles of iterative, value-based
incremental delivery by frequently gathering customer feedback and embracing change. This results in faster time to market, better delivery predictability,
increased customer responsiveness, ability to change direction by managing changing priorities, enhanced software quality, and improved risk management.
Scrum ensures discipline in the processes
You can evaluate whether you’re getting more throughput, delivering more value and where you need to make improvements

5. The key difference between Agile and Scrum is that while Agile is a project management philosophy which utilizes a core set of
values or principles, Scrum is a specific Agile methodology that is used to facilitate a project
Difference between Agile & Scrum
While Agile and Scrum follow the same system, there are some differences when comparing Scrum vs Agile. Agile describes a set of
principles in the Agile Manifesto for building software through iterative development. On the other hand, Scrum is a specific set of rules
to follow when practicing Agile software development. Agile is the philosophy and Scrum is the methodology to implement the Agile
philosophy.
Because Scrum is one way to implement Agile, they both share many similarities. They both focus on delivering software early and
often, are iterative processes, and accommodate change. They also encourage transparency and continuous improvement.
Agile and Scrum share similar methods like collaborative iterations, and for a good reason: Scrum is an Agile approach. But while both
involve incremental builds for projects, they also have their differences. Scrum is a more rigid method with less flexibility for change, and it’s
ideal for those who need to produce results as quickly as possible. Agile is more suited for smaller teams and for those who prefer a more
straightforward design and execution, while Scrum is used more for creative and experimental approaches.
It's best to look at it this way: Scrum is always Agile, but Agile is not always Scrum. This means Scrum will encompass the same
methodologies of Agile, but Agile may not share some of the same qualities as Scrum.

6. The Scrum
Values

7. The Scrum’s Simple
Rule

8. The Scrum Team

9. The Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters
do this by helping everyone understand Scrum theory, practices, rules, and values.
•Ensuring that goals, scope, and
product domain are understood by
everyone on the Scrum Team as well as
possible;
•Finding techniques for effective
Product Backlog management;
•Helping the Scrum Team understand
the need for clear and concise Product
Backlog items;
•Understanding product planning in an
empirical environment;
•Ensuring the Product Owner knows
how to arrange the Product Backlog to
maximize value;
•Understanding and practicing agility;
and,
•Facilitating Scrum events as requested
or needed.
Product Owner Development Team Organization
•Ensuring that goals, scope, and product
domain are understood by everyone on
the Scrum Team as well as possible;
•Finding techniques for effective
Product Backlog management;
•Helping the Scrum Team understand
the need for clear and concise Product
Backlog items;
•Understanding product planning in an
empirical environment;
•Ensuring the Product Owner knows
how to arrange the Product Backlog to
maximize value;
•Understanding and practicing agility;
and,
•Facilitating Scrum events as requested
or needed.
•Coaching the Development Team in self-
organization and cross-functionality;
•Helping the Development Team to create
high-value products;
•Removing impediments to the
Development Team’s progress;
•Facilitating Scrum events as requested or
needed; and,
•Coaching the Development Team in
organizational environments in which
Scrum is not yet fully adopted and
understood.
•Leading and coaching the organization
in its Scrum adoption;
•Planning Scrum implementations
within the organization;
•Helping employees and stakeholders
understand and enact Scrum and
empirical product development;
•Causing change that increases the
productivity of the Scrum Team; and,
•Working with other Scrum Masters to
increase the effectiveness of the
application of Scrum in the
organization.

10. Stories keep the
focus on the user. A
To Do list keeps the
team focused on
tasks that need
checked off, but a
collection of stories
keeps the team
focused on solving
problems for real
users.
Stories enable
collaboration. With
the end goal defined,
the team can work
together to decide
how best to serve the
user and meet that
goal.
Stories drive
creative
solutions. Stories
encourage the team
to think critically and
creatively about how
to best solve for an
end goal.
Stories create
momentum. With
each passing story
the development team
enjoys a small
challenges and a
small win, driving
momentum.
Why create user stories?
A user story describes the type of user, what they
want and why. A user story helps to create a
simplified description of a requirement.
The purpose of a user story is to articulate how a piece of work will
deliver a particular value back to the customer.
User stories are a few sentences in simple language that outline the
desired outcome. They don't go into detail. Requirements are added
later, once agreed upon by the team.
User Story

11. Product Backlog
Collection of all the User Stories is called Product
Backlog
A team's roadmap and requirements provide the
foundation for the product backlog
The Product Owner is the sole person responsible
for managing the Product Backlog
Product Backlog
management includes:
Clearly expressing Product Backlog
items;
Ordering the items in the Product
Backlog to best achieve goals and
missions
Optimizing the value of the work
the Development Team performs
Ensuring that the Product Backlog is
visible, transparent, and clear to all,
and shows what the Scrum Team will
work on next
Ensuring the Development Team
understands items in the Product
Backlog to the level needed

12. A sprint backlog is the set of items that a
cross-functional product team selects
from its product backlog to work on
during the upcoming sprint.
The development team is responsible
for sprint backlog management and
owns the sprint backlog
The development team should
communicate with the product owner
if they discover they cannot complete
a task
The Sprint Backlog is a forecast by the
Development Team about what
functionality will be in the next
Increment and the work needed to
deliver that functionality into a
"Done" Increment.
The Sprint Backlog is a forecast by the
Development Team about what
functionality will be in the next
Increment and the work needed to
deliver that functionality into a
"Done" Increment.
The Sprint Backlog is a highly visible, real-time picture of the
work that the Development Team plans to accomplish during the
Sprint, and it belongs solely to the Development Team.
Sprint Backlog

13. Product Backlog V/S Sprint Backlog

14. Release Planning
Release planning is longer-
term planning that enables us to answer
questions like “When will we be done?”
or “Which features can I get by the end
of the year?” or “How much will this
cost?”
Release planning is about making the scope, date, and budget trade-
offs for incremental deliveries. It is all about ‘high-level planning’ of
multiple sprints (three to twelve iterations). Most of the times, it is
sensible and important to carry out Initial Release Planning after
product planning and before beginning the first Sprint related to the
Release.
At this point, you can make an initial release plan showing a balance
between how much can be built in the release against when the
release will be available. You can generate and estimate a sufficient
number of product backlog items to get an idea of when you can
deliver a fixed set of features.

15. Sprint
In the Scrum Framework all activities needed for the implementation of entries from the Scrum Product Backlog are performed
within Sprints (also called 'Iterations'). Sprints are always short: normally about 2-4 weeks.
Each Sprint start with two
planning sessions to define the
content of the Sprint: the WHAT-
Meeting and the HOW-Meeting.
The combination of these two
meeting are also defined as Sprint
Planning Meeting. In the WHAT-
Meeting the Scrum Team commits
to the User Stories from the
Scrum Product Backlog and it
uses a HOW-Meeting to break the
committed User Stories into
smaller and concrete tasks. Then
implementation begins.
At the end of the Sprint a Sprint
Review Meeting is conducted to
allow the Scrum Product Owner
to check if all of the committed
items are complete and
implemented correctly.
Additionally a Sprint
Retrospective Meeting is
conducted to check and improve
the project execution processes:
What was good during the
Sprint, what should continue as
it is and what should be
improved.
During the Sprint a short daily Standup-Meeting (Daily Scrum
Meeting) is held to update the status of the items and to help self-
organization of the team.

16. 4
3
2
1
• Sprint Planning Meeting
• Daily Scrum / Daily Work
• Sprint Review
• Sprint Retrospective
Scrum Events -
Sprint

17. Sprint Planning
What Happens in Sprint Planning?
During Sprint Planning, the entire Scrum Team collaborates and discusses the desired high-priority work for the Sprint
and defines the Sprint Goal. The ScrumMaster’s role is primarily to facilitate the meeting. The Product Owner describes
the objective of the Sprint and also answers questions from the Development Team about execution and acceptance
criteria / criteria of satisfaction. The development team has the final say in how much of the high-priority work it can
accomplish during the Sprint.
Who attends Sprint Planning?
Sprint planning involves the entire Scrum Team: the development team, product owner, and ScrumMaster.
How long should Sprint Planning Last?
Sprint planning is limited to a maximum of eight hours.
The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means
teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint

18. Daily Scrum
What Happens in a Daily Scrum?
The Development Team meets for 15 minutes (or less) every day of the Sprint to inspect progress toward the Sprint
Goal. They describe for each other how their own work is going, ask for help when needed, and consider whether they
are still on track to meet the Sprint Goal. This is not a status meeting but is instead an opportunity for the Development
Team to inspect and adapt the product and process on a daily basis.
Who Attends the Daily Scrum?
The mandatory participants at the Daily Scrum are the development team. The ScrumMaster typically attends but is
optional. The product owner is invited but doesn’t have to attend.

19. Sprint Review
What Happens in a Sprint Review?
Sprint reviews focus on the product being developed, specifically on the potentially shippable product increment
created during the sprint. During a sprint review, the Scrum Team invites stakeholders to discuss what was completed
during the Sprint. They adapt the Product Backlog as needed based on this feedback. The Product Owner has the option
to release any of the completed functionality.
Though a demo might be part of this meeting, the primary purpose of the Sprint Review is the inspect and adapt
capability provided by the discussion.
Who Attends a Sprint Review?
The entire Scrum Team attends the sprint review. Any stakeholders, senior managers, and other affected departments
(e.g., marketing, customer support) are invited to attend and give feedback. Scrum teams should invite as many people
as the room can hold--diverse feedback is essential for creating excellent products.
How Long Should Sprint Reviews Last?
Sprint reviews are limited to a maximum of four hours.
The general rule of thumb is to allow one hours for sprint review per every one week of sprint length. That means
teams should timebox sprint review to two hours for a two-week sprint and four hours for a one-month sprint.

20. Sprint Retrospective
What Happens in a Sprint Retrospective?
Sprint retrospectives focus on the process. During a sprint retrospective the Scrum Team discusses what went right and
areas for improvement in the Sprint. They make tangible plans for how to improve their own process, tools and
relationships.
What Is the Difference between Sprint Reviews & Sprint Retrospectives?
Sprint reviews focus on the product. Sprint Retrospectives focus on the process.
Who Should Attend a Sprint Retrospective?
Sprint retrospectives are for the Scrum Team, which would include the development team, ScrumMaster, and product
owner. In practice, product owners are recommended but not mandatory attendees.
How Long Should Sprint Retrospectives Last?
Sprint retrospectives are limited to a maximum of three hours.
The general guidance is to allow 45 minutes for each week of sprint length. So a two-week sprint would cap the sprint
retrospective at an hour and a half; a four-week sprint at three hours.

22. Thank You