The document discusses the key events and artifacts in Scrum methodology. The main Scrum events are the Sprint, Sprint Planning, Daily Scrum meetings, Sprint Review, and Sprint Retrospective. Sprints have a fixed duration and are used to develop working product increments. Scrum artifacts include the Product Backlog, Sprint Backlog, and Increment which provide transparency. User stories written by product owners help define requirements and provide value to customers.

1. UNIT-III
SCRUM EVENTS

2. SCRUM - EVENTS
 Scrum Process Framework can be viewed by means of a
sequence of events and the corresponding artifacts.
 The Scrum events are time-boxed events. That means, in
a project, every scrum event has a predefined maximum
duration.
 These events enable transparency on the project progress
to all who are involved in the project. The vital events of
scrum are-
 The Sprint
 Sprint Planning
 Daily Scrum Meetings
 The Sprint Review
 The Sprint Retrospective

3. THE SPRINT
 During a Sprint, a working product Increment is
developed.
 It is usually of duration two weeks or one month, and
this duration remains constant for all the sprints in the
project.
 We cannot have varying durations for the different
sprints in a project.
 A new Sprint starts immediately after the conclusion of
the previous Sprint.

4.  It provides guidance to the Team on why it is building the
Increment.
 It is created during the Sprint Planning meeting. The
scope of the sprint is clarified and re-negotiated between
the Product Owner and the Team as more about the
requirements is learned.
 A Sprint should be cancelled if the Sprint Goal becomes
obsolete.
 This might occur if the organization changes direction or
if market or technology conditions change.
 A sprint can be cancelled only by product owner, though
others have an influence on the same.

5.  If a Sprint is cancelled, and part of the work produced
during the sprint is potentially releasable, the Product
Owner typically accepts it.
 All the incomplete Sprint Backlog Items are put back
into the Product Backlog.

6. SPRINT PLANNING
 The work to be performed in the Sprint is planned in the
Sprint Planning Meeting.
 Sprint Planning Meeting is of duration of maximum of
four hours for two weeks sprints and eight hours for one
month Sprints.
 It is the responsibility of the Scrum Master to ensure that
the meeting takes place and that all the required
attendees are present and understand the purpose of the
scheduled meeting.
 The Scrum Master moderates the meeting to monitor the
sustenance of discussion and closure on time.

7.  Sprint Planning focuses on the following two questions -
 What needs to be and can be delivered in the Sprint
Increment?
 How will the work needed for the execution of Sprint be
achieved?
 The inputs to this meeting are -
 The Product Backlog
 The latest product Increment
 Projected capacity of the Team during the Sprint
 Past performance of the Team

8.  The Scrum Team discusses the functionality that can be
developed during the Sprint.
 Product Owner provides clarifications on the Product
Backlog items.
 The team selects the items from the Product Backlog for
the Sprint, as they are the best to assess what they can
accomplish in the Sprint.
 The Team comprises of analysts, designers, developers,
and testers. The work is carried out in a collaborative
fashion, thus minimizing re-work.

9. FACTORS AFFECTING SPRINT PLANNING
• The What: The product owner describes the goal of the
sprint and the backlog items which contribute to achieve
that goal.
• The How: Agile development team plans its necessary
work on how to achieve and deliver the sprint goal.
• The Who: The product owner defines the goal based on
the value that the customers seek. And the developer
needs to understand how they can or cannot deliver that
goal.

10. • The Inputs: The product backlog provides the list of
input stuff that could potentially be part of the current
sprint. The team looks over the existing work done in
incremental ways.
• The Outputs: The critical outcome of sprint planning is
to meet described team goal. The product set the goal of
sprint and how they will start working towards the goal.

12. DAILY SCRUM MEETINGS
 The Daily Scrum Meeting is a 15-minute meeting for the
Team, conducted daily to quickly understand the work
since the last Daily Scrum Meeting and create a plan for
the next 24 hours.
 This meeting is also referred to as Daily Stand up
Meeting.
 The Daily Scrum Meeting is held at the same time and
same place every day to reduce complexity.

13.  During the meeting, each Team member explains -
 What did he do yesterday that helped the Team meet the
Sprint Goal?
 What will he do today to help the Team meet the Sprint Goal?
 Does he see any weaknesses that prevent him or the Team
from meeting the Sprint Goal?

14. Following are the benefits of Daily Scrum
Meetings –
 Improve communication within the Team.
 Identify impairments, if any, in order to facilitate an
early removal of the same, so as to minimize impact
on the Sprint.
 Highlight and promote quick decision-making.
 Improve the Team’s level of knowledge.

15. SPRINT REVIEW
 A Sprint Review is held at the end of every Sprint.
 During the Sprint Review, a presentation of the
increment that is getting released is reviewed.
 In this meeting, the Scrum Team and the stakeholders
collaborate to understand what was done in the Sprint.
 Thus, the objective of Sprint Review is to obtain
feedback and progress.
 The Sprint Review is normally held for two hours for
two week sprints and for four hours for one month
sprints.

16. The Scrum Master ensures that -
 The meeting takes place.
 The participants understand the purpose.
 The meeting is focused on the required agenda and is completed
within the required duration.
The Sprint Review includes the following aspects -
 Attendees include the Scrum Team and key stakeholders, as
invited by the Product Owner.
 The Product Owner explains what Product Backlog items have
been completed during the sprint and what has not been
completed.
 The Team discusses what went well during the Sprint, what
problems it ran into, and how those problems were solved.

17.  The Team demonstrates the work that it has completed
and answers questions, if any, about the Increment.
 The entire group then discusses on what to do next.
Thus, the Sprint Review provides valuable input to
Sprint Planning of the subsequent Sprint.
 The Scrum Team then reviews the timeline, budget,
potential capabilities, and marketplace for the next
anticipated release of the product increment.
 The outcome of the Sprint Review is an updated Product
Backlog, which defines the probable Product Backlog
items for the next Sprint.

18. SPRINT RETROSPECTIVE
 The Sprint Retrospective occurs after the Sprint Review
and prior to the next Sprint Planning.
 This is usually a one hour meeting for two-week duration
sprints and a three hour meeting for one month duration
Sprints.
 The purpose of the Sprint Retrospective is to -
 Combine the learning's from the last Sprint, with regards to
people, relationships, process, and tools.
 Identify the major items that went well and potential
improvements.
 Creation of a plan for implementing improvements to
increase product quality.

19. SCRUM- ARTIFACTS
 Scrum Artifacts provide key information that the Scrum
Team and the stakeholders need to be aware of understanding
the product under development, the activities being planned,
and the activities done in the project.
 The following artifacts are defined in Scrum Process
Framework.
 Product Vision
 Sprint Goal
 Product Backlog
 Sprint Backlog
 Definition of Done
 Burn-Down Chart
 Increment

20. PRODUCT VISION
 The Product Vision is an artifact to define the long-term
goal of the project/product.
 It sets the overall direction and guides the Scrum Team.
 Everyone should be able to memorize the Product
Vision; therefore it must be short and precise.

21. SPRINT GOAL
 Sprint goals help to focus the sprint. It is achieved during
the Sprint by implementing forecasted product backlog
items, and it provides guidance to the development team
as to why product increments should be built.
 As per the Scrum Guide, the responsibility for crafting a
Sprint Goal is for the Scrum Team.
 It is however in large part of interest to the Product
Owner to support this process by having clear business
goals for the coming Sprint, which can also make
ordering the Product Backlog a lot easier by providing
Focus.

22. PRODUCT BACKLOG
 A product backlog is a list of all the things that are
required in the product and it is a dynamic and best
understood requirements for any changes to be made to
the product.
 Product backlog owned by the Product Owner (PO)
which consists of a lists all features, functions,
requirements, enhancements, and fixes that constitute the
changes to be made to the product in the future releases.

24.  Typically, the requirements of a product keep changing,
i.e. change in business requirements, market conditions,
or technology.
 Thus, product backlog is consistently updated to reflect
what the product needs to be most useful to the target
users.

25. SPRINT BACKLOG
 The Sprint Backlog is the set of Product Backlog items
selected for the Sprint plus a plan for delivering the
product Increment and realizing the Sprint Goal.
 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.
 The Sprint Backlog defines the work the Development
Team will perform to turn Product Backlog items into a
“Done” Increment.
 The Sprint Backlog makes visible all of the work that the
Development Team identifies as necessary to meet the
Sprint Goal.

27. DEFINITION OF DONE
 Every Product Backlog item has acceptance criteria that
define measurably what must be met when the item is
declared to be done.
 the Definition of Done is a shared understanding of the
Scrum Team on the meaning of work to be complete.
 It typically contains quality criteria, constraints and
overall non-functional requirements. Here is some
examples:-

29. INCREMENT
 The Increment is the sum of all the Product Backlog items
completed during a Sprint and all previous Sprints.
 At the end of a Sprint, the new Increment must be
“Done,” which means:
 It must meet the Scrum Team’s Definition of “Done.”
 It must be in usable condition regardless of whether the
Product Owner decides to actually release it.

30. THE BURNDOWN CHART
 These are graphs that give an overview of progress over
time while completing a project. As tasks are completed,
the graph “burns down” to zero.
 It is used as a tool to guide the development team to a
successful completion of a Sprint on time with a working
final product.
 The following sprint burndown chart is displayed
showing remaining tasks in the sprint backlog. Updated
every day, it gives a simple view of the sprint progress. It
also provides quick visualizations for reference.

32. USER STORIES
 In Agile a user story is a short, informal, plain language
description of what a user wants to do within a software
product to gain something they find valuable.
 Its main purpose is to provide software features that will
add value to the customer requirements.
 User stories are considered an important tool in
Incremental software development.
 Mainly a user story defines the type of user, their need,
and why they need that.

33. PATTERN OF USER STORY :
 User stories are completely from the end-user
perspective which follows the Role-Feature-Benefit
pattern.
As a <Type of User>,
I want <To Perform Some Task>,
So that <I can achieve some goal/benefit/value>.
o User stories can be even created on cards or sticky
notes and arranged on walls to encourage discussion
and planning activities.

34. GOAL OF THE USER STORY
 The key goal of any user story is to write down how a
certain project will deliver value back to the end-user.
 Ideally, the development team should collaborate with
stakeholders and business owners to clarify the details as
the code gets developed.

35. INVEST PRINCIPLE OF USER STORY
 Independent. A well-written story should be
independent of other stories to allow you freely move it
around the backlog when priorities change.
 Negotiable. All the details of a story should be created in
collaboration between customers and the team.
Negotiating the scope is a must.
 Valuable. Efficient user stories provide customers with
value. There is no sense to put effort into the story
without value.

36.  Estimable. Without the ability to estimate a story, you
will not understand the scope.
 Small. Big Agile stories are difficult to estimate, and
they are less negotiable.
 Testable. If your customers and the whole team cannot
specify how to verify you have implemented what they
want, you haven’t added enough clarity about this user
story.

37. C’S IN USER STORIES
 Card –
Write stories on cards, prioritize, estimate and schedule it
accordingly.
 Conversation –
Conduct conversations, Specify the requirements and
bring clarity.
 Confirmation –
Meet the acceptance criteria of the software.

38. WORKING WITH USER STORIES :
 Once the user story is fully written then it undergoes
review and verification.
 In project workflow meetings it is reviewed and verified
then added to the actual workflow.
 Actual requirements and functionality are decided based
on the stories.
 User stories are scored based on their complexity and the
team starts work based on user stories.

39. IMPORTANCE OF CREATING USER STORIES :
 Stories clear idea about requirements
 Makes it easy to understand the features
 Delivers higher customer satisfaction
 Fasten development process
 Creates an effective work environment
 Enables collaboration between teams
 Delivery of valuable software

40. LIFECYCLE OF A USER STORY
1. Pending
 You may generate Scrum user stories based on
communication between the members of your Agile team
and users. These stories will contain a brief description
of users’ needs.
2. To-do state
 During the discussion session between all the parties
involved, the stories that will be reviewed in the next
weeks are determined. They move to a sprint and get a
“to-do” state.

41. 3. Discussing
 Now it is time for the discussing state when developers
communicate with the end-user. They discuss
requirements’ confirming and the acceptance criteria.
4. Developing
 After clarifying all requirements, the development team
starts to design features and implement them.

42. 5. Confirming
 When your story is implemented, it’s high time to
confirm it with the end-user (who gets access to testing).
The confirmation items noted while detailing the story
will be the basis for confirmation.
6. Finish
 This state means that the features are confirmed and
done. This is the end of the user story.

43. EXAMPLE
User Story: Customer’s Cash Withdrawal
As a Customer,
I want to withdraw cash from an ATM,
So that I don't have to wait in line at the Bank

44. USER STORY ACCEPTANCE CRITERIA
Each User Story also has Acceptance Criterion defined,
so that correctness of implementation of the user story is
confirmed by passing the Acceptance Test that is based
on the Acceptance Criterion.
Acceptance Criterion 1:
Given that the account is creditworthy
 And the card is valid
 And the dispenser contains cash,
When the customer requests the cash
Then ensure the account is debited
 And ensure cash is dispensed
 And ensure the card is returned.

45. Acceptance Criterion 2:
Given that the account is overdrawn
 And the card is valid
When the customer requests the cash
Then ensure the rejection message is displayed
 And ensure cash is not dispensed
 And ensure the card is returned.

46. THANK YOU