The document discusses Scrum, an agile framework for managing product development. It describes key Scrum concepts like sprints, daily stand-ups, product and sprint backlogs, and roles like the Scrum Master and Product Owner. Scrum uses short development cycles called sprints to incrementally deliver working software. Teams self-organize during sprints to progress features on the product backlog.

1. By Pruthviraj Yerram

2.  The two dominant Agile approaches are Scrum and eXtreme
Programming (XP).
 XP was arguably the first method deemed to be “Agile”.
 We will start with Scrum – very popular and in very wide use today!

3.  Based on the concept that software development is
not a defined process but an empirical
process
with complex input/output
transformations that
may or may not be repeated under
differing circumstances.

4.  Scrum: a definite project management emphasis.
 Scrum Master: A Scrum project Is managed by a Scrum
Master, who can be considered as much a consultant or coach
as a manager.
 Sprint. Scrum has a fundamental 30-day development cycle
called a Sprint, preceded by
 pre-Sprint activities and post-Sprint activities.
 Daily Scrum: A short (less than 30 minutes) daily Scrum
Meeting allows the team to monitor status and communicate
problems.

5. Project planning is based on a Product Backlog,
which contains
 functions and
 technology enhancements
envisioned for the project.
Two meetings are held –
 one to decide the features for the next Sprint and
 the other to plan out the work.

6. Additionally, a Sprint Goal is established.
Sprint Goal sets up minimum success criterion
for the Sprint and
keeps the team focused on the broader picture
rather than narrowly on the task at hand.
This is really the objective of the Sprint.

7.  Scrum is a means of introducing agile methods into a traditionally disciplined
environment.
 Because of this, Scrum has gained widespread popularity!
 Scrum can be used for one or more components of the system and this allows
management to assess Scrum effectiveness without completely changing the
way the organization normally does business.
 Scrum is NOT Extreme Programming

8.  Scrum: one of the few agile methods used to scale upfor larger
projects.
 How done?
Accomplished the same way as organizations
handle integrated product teams.
Individual Scrum team coaches - part of a
higher echelon team of coaches spanning
several products.
This provides for communications to avoid
conflicting development issues

10.  Product Backlog  Sprint Backlog  Sprint  Working increment of the Software
 Scrum uses lightweight queue-based management and work-breakdown
mechanisms.
 Product Backlog queue: a low-tech customer-managed queue of demand requests
for products.
 Sprint: At launch time, a Sprint (30-day time-boxed iteration) does just-in-time
planning
 Sprint Backlog: queue for Sprint work-mgmt.

11.  Daily Scrum: Very notable and very visible
 Is a daily standup,
 except that it is the team that is participating and sharing coordination information
not a central project manager.
 Project Manager = Scrum Master – sort of…
 Scrum Master
 holds daily scrum and
 acts more as a facilitator and runs interference for the core team when blocks or
issues arise.

12. Three core roles and a range of
ancillary roles
Core roles:
Core roles are those committed to the
project in the Scrum process
Core roles are those producing the
product
They represent the Scrum team.

13. The Product Owner represents the stakeholders
and is the voice of the customer.
Product Owner is accountable for ensuring that
the team delivers value to the business.
Product Owner
 writes customer-centric items (typically user stories),
 prioritizes them, and
 adds them to the product backlog.
Note:
Scrum teams should have one Product Owner.
May also be a member of the development team
Not recommend this person be Scrum Master.

14.  The Development Team is responsible for delivering
potentially shippable product increments at end of
each Sprint.
 Team = 3–9 people with cross-functional skills.
 Team does actual work
 (analyze, design, develop, test, technical communication,
document, etc.).
 Team is self-organizing, even though they may
interface with project management organizations
(PMOs).

15. Scrum is facilitated by a Scrum Master –
Accountable for removing impediments for team
to deliver sprint goal / deliverables.
Scrum Master is not the team leader, but acts as a
buffer between the team and any distracting
influences.
Scrum Master ensures process is used as intended.
Scrum Master is the enforcer of rules.
Scrum Master’s role: protect the Team and keep it
focused on the tasks at hand.

16.  Ancillary roles in Scrum teams: have no formal role and
infrequent involvement in the Scrum process—but
nonetheless, they must be taken into account.
 Stakeholders
 Are the customers, vendors.
 Stakeholders: enable the project
 Stakeholders are those for whom the project produces the
agreed-upon benefit[s] that justify its production.
 Only directly involved in the process during sprint reviews.
 Managers
 People who control the environment.

17. Sprint: basic unit of development in Scrum.
Sprint duration: one week to one month;
“Time Boxed" effort of a constant length.
Each sprint:
Preceded by a planning meeting,
 where the tasks for sprint are identified and an
 estimated commitment for the sprint goal made,
and followed by
 a review or retrospective meeting, where the
progress is reviewed and lessons for the next sprint
are identified.

18.  During each Sprint, the team creates finished portions of a product. (an
increment)
 Features going into a Sprint come from the product backlog, which is a
prioritized list of requirements.
 Which backlog items go into the sprint (sprint goals) are determined during
the Sprint Planning meeting.
 The Product Owner decides which items in the product backlog are to be
completed

19.  The team then determines how many selected items can
be completed during the next sprint.

These then go into the Sprint Backlog.
 Sprint Backlog is property of the development team,
During a sprint, no one is allowed to edit the sprint
backlog except for the development team.
 Development is timeboxed; Sprint must end on time;
 Requirements not completed for any reason?
 They are omitted and returned to Product Backlog.
 When Sprint is done, team demonstrates software.

20.  Scrum enables self-organizing teams
 Encourages co-location of all team members,
 Scrum developers realize customers can change
their minds about wants and needs.
 Scrum developers realize unpredicted challenges
cannot be easily addressed in a traditional planned
manner.
 Scrum adopts an empirical approach.
 Scrum realizes problems cannot be fully
understood or defined,

21.  Like other agile development methodologies, Scrum can be
implemented through a wide range of tools.
 Many companies use universal tools, such as spreadsheets to
build and maintain artifacts.
 In Scrum, there are many open-source and proprietary
packages dedicated to management of products.
 Some organizations implement Scrum without the use of any
tools.
 These maintain their artifacts in hard-copy forms such as
paper, whiteboards, and sticky notes.

23.  Every day there is a daily scrum.
 Meeting has specific guidelines: Meeting starts on time.
 All are welcome, but normally only the core roles speak
 The meeting length is set to 15 minutes
 Meeting should happen at same location and same time every day
 During the meeting, each team member answers three questions:
• What have you done since yesterday?
• What are you planning to do today?
• Any impediments/stumbling blocks?
 It is role of the Scrum Master to address problems.
 Resolution should occur outside Daily Scrum to keep it under 15 min.

24.  The team should spend time during a sprint doing product
backlog grooming.
 This is the process of estimating the existing backlog using
effort/points, refining the acceptance criteria for individual
stories, and breaking larger stories into smaller stories.
 Meetings should not be longer than an hour
 Meeting does not include breaking stories into tasks
 Team can decide how many meetings are needed per week.

25.  Held each day normally after the Daily Scrum.
 These meetings allow clusters of teams to discuss their work,
focusing especially on areas of overlap / integration.
 A designated person from each team attends.
 The agenda will be the same as the Daily Scrum, plus the
following four questions:
• What has your team done since we last met?
• What will your team do before we meet again?
• Is anything slowing your team down or getting in their way?
• Are you about to put something in another team’s way?

26.  At the beginning of the sprint cycle (every 7–30 days), a “Sprint Planning
meeting” is held.
 Select what work is to be done
 Prepare the Sprint Backlog that details the time it will take to do that work,
with the entire team
 Identify and communicate how much of the work is likely to be done during
the current sprint
 Eight-hour time limit
• (1st four hours) Entire team: dialog for prioritizing the Product Backlog
• (2nd four hours) Development Team: hashing out a plan for the Sprint, resulting
in the Sprint Backlog
 At the end of a sprint cycle, two meetings are held: the “Sprint
Review Meeting” and the “Sprint Retrospective”

27. • Review the work that was completed and not completed
• Present the completed work to the stakeholders (a.k.a. “the
demo”)
• Incomplete work cannot be demonstrated
• Four-hour time limit

28.  Sprint Retrospective
 All team members reflect on the past sprint
 Make continuous process improvements
 Two main questions are asked in the sprint retrospective:
• What went well during the sprint?
• What could be improved in the next sprint?
 Three-hour time limit

30.  Product backlog is an ordered list of "requirements" that is maintained for a
product
 Contains Product Backlog Items ordered by the Product Owner based on
 considerations like risk,
 business value,
 dependencies,
 date needed, etc.
 Features added to backlog commonly written in story format
 The product backlog is the “What” that will be built, sorted in the relative
order it should be built in.
 Is open and editable by anyone,
 Product Owner is ultimately responsible for ordering the stories on the backlog for the
Development Team.

31.  The product backlog contains rough estimates of both business value
and development effort, these values are often stated in story points
using a rounded Fibonacci sequence.
 Those estimates help the Product Owner to gauge the timeline and
may influence ordering of backlog items.
 Example, if the “add spellcheck” and “add table
support” features have the same business value, the
one with the smallest development effort will probably
have higher priority, because the Return on
Investment is higher.

32.  Product Owner: responsible for the product backlog and the business
value of each item listed.
 Development Team: responsible for the estimated effort to complete
each backlog item.
 Team contributes by estimating Items and User-Stories, either in
“Story-points” or in “estimated hours.”

33.  Sprint Backlog: list of work the Development Team must
address during the next sprint.
 List derived by selecting stories/features from the top of the
product backlog until the Development Team feels it has
enough work to fill the sprint.
 Thinking: This is done by the Development Team asking
"Can we also do this?" and adding stories/features to the
sprint backlog.
 History: Development Team should note velocity of
previous Sprints (total story points completed from each of
the last sprints stories) when selecting stories/features for
the new sprint.
 Use number as guide for "effort" they can complete.

34.  Stories/features: broken down into tasks by Development Team
 Should normally be between four and sixteen hours of work.

 With this level of detail the Development Team understands exactly what to do, and
potentially, anyone can pick a task from the list.

 Tasks on sprint backlog are never assigned; tasks signed up for by team members as
needed during daily scrum, according to the set priority and the Development Team
member skills.
 Promotes self-organization of Team, and developer buy-in.
 Sprint backlog is property of Team, and all included estimates are provided by the
Development Team.

 Often an accompanying task board used to see/change state of the tasks of the current
sprint, like “to do”, “in progress” and “done”.

35.  The ”increment” is sum of all Product Backlog Items completed
during a sprint and all previous sprints.
 At end of a sprint, Increment must be done according to Scrum
Team's definition of done.
 The increment must be in usable condition regardless of
whether the Product Owner decides to actually release it.

36.  The sprint burn down chart is a publicly displayed chart showing
remaining work in the sprint backlog.
 Updated every day; gives a simple view of the sprint progress.
 Other types of burn down:
 Release burn down chart: shows amount of work left to complete the
target commitment for a Product Release
 This normally spans multiple iterations
 Alternative Release burn down chart: basically does the same, but clearly
shows scope changes to Release Content, by resetting the baseline.
 This should not be confused with an earned value chart.

38. Scrum Team:
Product Owner, Scrum Master and Development Team
 Product Owner: The person responsible for maintaining the Product Backlog by
representing the interests of the stakeholders, and ensuring the value of the work the
Development Team does.
 Scrum Master: The person responsible for the Scrum process, making sure it is used
correctly and maximizing its benefits.
 Development Team: A cross-functional group of people responsible for delivering
potentially shippable increments of Product at the end of every Sprint.

39. Sprint burn down chart: Daily progress for a Sprint
over the sprint’s length.
Product backlog: A prioritized list of high-level
requirements.
Sprint backlog: A prioritized list of tasks to be
completed during the sprint.
Sprint: A time period (typically 1–4 weeks) in which
development occurs on a set of backlog items that the
team has committed to. (commonly referred to as a
Time-box or iteration)

40.  (User) Story: A feature added to the backlog is commonly referred to
as a story; has a specific suggested structure.
The structure of a story is: "As a <user
type> I want to <do some action> so that
<desired result>"
 Done so development team can identify user, action and required
result in a request; simple way of writing requests anyone can
understand.
 Example: As a wiki user I want a tools menu on the edit screen so that I
can easily apply font formatting.

41. A story is an
 independent,
 negotiable,
 valuable,
 estimatable,
 small,
 testable requirement
Despite being independent, stories have no
direct dependencies with other requirements.
Stories may be clustered into epics (a group of
related stories) when represented on a product
roadmap or further down in the backlog.

42.  Tasks: Added to story at beginning of a sprint and
broken down into hours.
 Each task should not exceed 12 hours, but it's common for
teams to insist that a task take no more than a day to finish.
 Definition of Done (DoD): The exit-criteria to
determine whether a product backlog item is
complete.
 In many cases the DoD requires that all regression
tests should be successful.

43. Velocity: The total effort a team is capable of in a
sprint. The number is derived by adding all the
story points from the last sprint's stories/features.
This is a guideline for the team and assists them in
understanding how many stories they can do in a
sprint.
Impediment: Anything that prevents a team
member from performing work as efficiently as
possible.