Scrum is an agile framework for managing projects, commonly used for software development. It utilizes empirical process control through short cycles of work called sprints, daily stand-up meetings, and artifacts like product backlogs and sprint backlogs. The scrum team consists of the product owner, scrum master, and development team. They participate in events like sprint planning, daily scrums, sprint reviews, and retrospectives. The goal is to frequently inspect work, adapt the process as needed, and transparently deliver working software increments within each sprint.

1. Scrum in IT Industry
Part 2
-Jayesh Patil

3. Scrum is an agile way to manage a project, usually software development.
 Agile software development with Scrum is often perceived as a methodology; but rather than
viewing Scrum as methodology, think of it as a framework for managing a process.
A framework within which people can address complex adaptive problems, while productively and
creatively delivering products of the highest possible value .

4. Scrum Theory
Scrum is founded on empirical process
control theory, or empiricism.
Empiricism asserts that knowledge comes from
experience and making decisions based on what is
known.
Scrum employs an iterative, incremental approach to
optimize predictability and control risk.

5. Pillars of Scrum

6. Scrum Pillars contd….
Transparency :
Significant aspects of the process must be visible to those responsible for the outcome.
Transparency requires those aspects be defined by a common standard so observers share a
common understanding of what is being seen.
Inspection :
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect
undesirable variances.
Their inspection should not be so frequent that inspection gets in the way
Adaptation :
If an inspector determines that one or more aspects of a process deviate outside acceptable
limits, and that the resulting product will be unacceptable, the process or the material being
processed must be adjusted. An adjustment must be made as soon as possible to minimize
further deviation.
Scrum

7. Scrum Roles - The Scrum Team
Within the Scrum Framework three roles are defined:
Each of these roles has a defined set of responsibilities and only if they fulfill these
responsibilities, closely interact and work together they can finish a project successfully.

8. The Product Owner
 The Product Owner is responsible for maximizing the value of the product
resulting from work of the Development Team
 The Product Owner is the sole person responsible for managing the Product
Backlog.
 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.
 The Product Owner may do the above work, or have the Development Team do it.
 The Product Owner is one person, not a committee. The Product Owner may
represent the desires of a committee in the Product Backlog, but those wanting to
change a Product Backlog item’s priority must address the Product Owner.
 The entire organization must respect his or her decisions.

9. The Development Team
 The Development Team consists of professionals who do the work of
delivering a potentially releasable Increment.
 Development Teams have the following characteristics:
 • They are self-organizing. No one (not even the Scrum Master) tells the
Development Team
 how to turn Product Backlog into Increments of potentially releasable
functionality;
 • Development Teams are cross-functional, with all the skills as a team
necessary to create a
 product Increment;
 • Scrum recognizes no titles for Development Team members,
regardless of the work being
 performed by the person;
 • Scrum recognizes no sub-teams in the Development Team, regardless
of domains that need
 to be addressed like testing, architecture, operations, or business
analysis; and,
 • Individual Development Team members may have specialized skills
and areas of focus, but
 accountability belongs to the Development Team as a whole.

10. 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.
 The Scrum Master is a servant-leader for the Scrum Team.
 The Scrum Master helps those outside the Scrum Team understand which of their interactions with
the Scrum Team are helpful and which aren’t.
 The Scrum Master helps everyone change these interactions to maximize the value created by the
Scrum Team.

11. Characteristics of a Scrum Team
 Scrum Teams always have the following characteristics:
 Team members share the same norms and rules
 The Scrum team as a whole is accountable for the delivery
 The Scrum Team is empowered
 It is working as autonomous as it is possible
 The Scrum Team is self organizing
 The skills within the Scrum team are balanced
 A Scrum Team is small and has no sub-teams
 The people within the Scrum Team work full time in the team
 People are collocated

12. SCRUM Quick flash
3 Roles: 1)Product Owner 2) Scrum Master 3) Scrum Team/Dev Team
3Pillars : 1) Transparency 2) Inspection 3) Adaptation

13. Rules & Norms
The environment defines some of the norms the teams have to follow, but some rules and norms are
developed during the Norming phase.
This set of common rules is quite important. Otherwise the team members would have to constantly
waste valuable time to switch between different value systems and rule sets.
Examples for such norms and rules are:
1) Time and location of the Daily Scrum Meeting
2)The Definition Of Done (DoD) used to decide if work is finished or not
coding guidelines
3)Tools to use

14. Accountability
The Scrum Team as a whole is responsible to deliver the committed delivery in time and
with the defined quality.
A good result or a failure is never attributed to a single team member but always the result of the
Scrum Team.

15. Empowerment & Self organization
The Scrum Team has to be empowered to definewhat it will commit to deliver at the end of the
sprint
how the expected results have to be broken down into tasks
who will perform the task and in which order they are performed
Only if the Scrum Team is empowered to decide these things it will work with the highest
possible motivation and performance.

16. Balanced set of skill
 Individuals within the Scrum Team will most certainly have specialized skills and focus.
 However to achieve best possible performance it would be optimal to have a balanced set of
skills.
 Only then the Scrum Team will be able to deal with the ever-changing challenges and can act
as autonomous as it is possible.
On one hand this means that a Scrum Team should be multidisciplinary (developers, tester,
architects etc) right from the beginning.
 On the other hand this also means that each team member should learn a little bit of each
other's specialization, e.g. a if required to finally reach the committed goal a developer should
also perform or write tests.
As a consequence this also means that within the Scrum Framework it is not differentiated
between e.g. "tester" and "architect", they all share the same title "Scrum Team Member" even
if the primary skill is not to develop production code.

17. Size of the Scrum Team
 Scrum Teams are small. The ideal size is 3-9 .
 If there are more people the communication overhead gets too large and the team should be
split into multiple Scrum Teams.
 These Scrum Teams should be coordinated and communicate with each other but otherwise
work independently.

18. Collocation
To minimize unnecessary communication
overhead each Scrum Team should be
collocated. If work has to be spread over
multiple locations, independent Scrum Teams
should be created.

19. Responsibilities of the Scrum Team
 The Scrum Team and each of the team members has certain responsibilities which have to
be fulfilled
 They have to breakdown the requirements, create task, estimate and distribute them. In
other words this means that they have to create the Sprint Backlog.
 They have to perform the short Daily Sprint Meeting.
 They have to ensure that at the end of the Sprint potentially shippable functionality is
delivered.
 They have to update the status and the remaining efforts for their tasks to allow creation of
a Sprint Burndown Diagram.

20. Scrum Values
1) Commitment....
2) Focus. ...
3) Openness. ...
4) Respect. ...
5) Courage.

21. Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection
and adaptation.
1) Product Backlog
2) Sprint Backlog
3) Increment

22. Product Backlog
 The Product Backlog is an ordered list of everything that is known to be needed in the
product.
 The Product Owner is responsible for the Product Backlog, including its content,
availability, and ordering.
 The Product Backlog lists all features, functions, requirements, enhancements, and fixes that
 constitute the changes to be made to the product in future releases.
 Product Backlog items have the attributes of a description, order, estimate, and value.
Product Backlog items often include test descriptions that will prove its completeness when
“Done.”
 A Product Backlog is never complete.
 Multiple Scrum Teams often work together on the same product. One Product Backlog is
used to describe the upcoming work on the product.
 A Product Backlog attribute that groups items may then be employed.

23. 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 into a “Done” Increment.
 The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to
meet the Sprint Goal.
 The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the
Daily Scrum.
 As new work is required, the Development Team adds it to the Sprint Backlog.
 As work is performed or completed, the estimated remaining work is updated.
 When elements of the plan are deemed unnecessary, they are removed.
 Only the Development Team can change its Sprint Backlog during a Sprint.

24. Product Increment
 The Increment is the sum of all the Product Backlog items completed during a Sprint and
the value of the increments of all previous Sprints.
 At the end of a Sprint, the new Increment must be “Done,” which means it must be in
useable condition and meet the Scrum Team’s definition of “Done.”
 The increment is a step toward a vision or goal.
 The increment must be in useable condition regardless of whether the Product Owner
decides to release it.

25. Scrum Ceremonies/Events
 Prescribed events are used in Scrum to create
regularity and to minimize the need for meetings
not defined in Scrum.
 All events are time-boxed events, such that every
event has a maximum duration.
 Once a Sprint begins, its duration is fixed and
cannot be shortened or lengthened.
 The remaining events may end whenever the
purpose of the event is achieved, ensuring an
appropriate amount of time is spent without
allowing waste in the process.

26. The Sprint
 The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”,
useable, and potentially releasable product Increment is created.
 Sprints have consistent durations throughout a development effort.
 A new Sprint starts immediately after the conclusion of the previous Sprint.
 Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the
Sprint Review, and the Sprint Retrospective.

27. Cancelling a Sprint
 A Sprint can be cancelled before the Sprint time-box is over.
 Only the Product Owner has the authority to cancel the Sprint, although he or she may do so
under influence from the stakeholders, the Development Team, or the Scrum Master.
 A Sprint would be cancelled if the Sprint Goal becomes obsolete.
 In general, a Sprint should be cancelled if it no longer makes sense given the circumstances.
But, due to the short duration of Sprints, cancellation rarely makes sense.

28. Sprint Planning
There are two defined artifacts that result from a sprint planning meeting:
 A sprint goal
 A sprint backlog
Sprint Goal : A sprint goal is a theme for the sprint ,as the essential focus of the sprint.
Product owner shall share the sprint Goal ,created during the sprint planning .
Sprint Planning is a collaborative efforts involving a scrum master ,who facilitates the meeting ,a product owner ,who
clarifies the details of the product backlog item and their respective acceptance criteria ,and the entire agile team.who
defines the work and effort necessary to meet their sprint commitment.
It’s the 1st meeting to Kick off the sprint .
Duration: 2hrs/ week of sprint
Who will attend:In Scrum, the sprint planning meeting is attended by the product owner, ScrumMaster and the entire
Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies. During the
sprint planning meeting, the product owner describes the highest priority features to the team.

30. Sprint Planning meeting
The Sprint Planning Meeting is typically broken into two parts.
Part 1:
 Part one of the sprint planning meeting is a review of the product backlog items the Product Owner will ask
the team to forecast and deliver.
 This is the time for the product owner to describe what she wants to see built for the next sprint.
 During this part of the meeting, it is not uncommon for the team to banter back and forth with the product
owner, asking clarifying questions and driving away ambiguity.
 sprint planning part one, the team will select a sprint goal: a one-sentence description of the overall outcome
of the sprint
Part 2:
 During part two of the sprint planning meeting, the team decides how the work will be built.
 In this meeting the team will begin decomposing the product backlog items into work tasks and estimating
these in hours.
 The product owner must be available during this meeting but does not have to be in the room.
 The output of the second planning meeting will be the Sprint Backlog.

31. Daily Scrum
 The Daily Scrum is held every day of the Sprint.
 The Daily Scrum is a 15-minute time-boxed event for
the Development Team.
 • What did I do yesterday
 • What will I do today
 • Do I see any impediment that prevents me or the
Development Team from meeting the Sprint Goal?
 The Daily Scrum is an internal meeting for the
Development Team. If others are present, the Scrum
Master ensures that they do not disrupt the meeting.

32. Sprint Review
• A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if
needed.
• During review meeting, the Scrum team shows what they accomplished during the sprint. Typically this
takes the form of a demo of the new features.
• The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of
PowerPoint slides and allowing no more than two hours of preparation time for the meeting.
• Participants: the product owner, the Scrum team, the ScrumMaster, management, customers and
developers from other projects.
• Duration: 1hrs/week of sprint

33. Sprint Retrospective
• 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.
• The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
• Duration: 3hrs /month sprint
• The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it
within the time-box.
• The purpose of the Sprint Retrospective is to:
• • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• • Identify and order the major items that went well and potential improvements; and,
• • Create a plan for implementing improvements to the way the Scrum Team does its work.
• By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will
implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the
inspection of the Scrum Team itself.

34. Velocity
 The Velocity is a measure of the amount
of work a team can tackle during a single
sprint and is the key metric in Scrum .
 The estimate is based on the past
records/performance of the team.
 It is calculated by averaging the total
amount of story points completed over
the number of sprints completed .
 Eg: If a team has completed 3 sprints
having 65,70,100 sprint points
respectively ,then the velocity at that
point is 80 story points .

35. SCRUM Quick flash
3 Roles: 1)Product Owner 2) Scrum Master 3) Scrum Team/Dev Team
4 Cermonies/Events:
a) Sprint Planning
b) Daily Scrum
c) Sprint Review
d) Sprint retrospective
3 Artifacts : 1)Product Backlog 2)Sprint Backlog 3)Product Increment
3Pillars : 1) Transparency 2) Inspection 3) Adaptation
5 Values : 1) Openness 2) commitment 3)Courage 4) Focus 5) Respect

36. User Stories
 User stories are short, simple
descriptions of a feature told
from the perspective of the
person who desires the new
capability, usually
a user or customer of the
system.
 They typically follow a simple
template: As a < type of user >,
I want < some goal > so that <
some reason >.

37. Estimation
 The Scrum Estimation of User Stories is in
terms of the degree of difficulty for each of the
User Stories.
 Relative estimation is done
 Here are 7 agile estimation techniques
 Planning Poker.
 T-Shirt Sizes. ...
 Dot Voting. ...
 The Bucket System. ...
 Large/Uncertain/Small. ...
 Affinity Mapping. ...
 Ordering method.

38. Estimation Techniques
 The 7 agile estimation techniques
1) Planning Poker.
2) T-Shirt Sizes. ...
3) Dot Voting. ...
4) The Bucket System. ...
5) Large/Uncertain/Small. ...
6) Affinity Mapping. ...
7) Ordering method.

39. Planning Poker
 Planning Poker is an agile estimating and
planning technique that is consensus based.
 Most teams will hold a Planning Poker session
shortly after an initial product backlog is written.
 Planning Poker can be used with story points,
ideal days, or any other estimating unit.
 Planning Poker leads to better estimates is
because it brings together multiple expert
opinions.
 Story Points are used as the measurement,
Fibonicc series is generally used .

40. Story Points
 The story points are a unit of
measure for expressing an
estimate of the overall effort that
will be required to fully
implement a product backlog item
or any other piece of work.
 In story sizing ,team does
comparative analysis between all
of the stories for the project .

41. Story point Vs Time based/Man hours
estimation
 Story Point estimation
 1)The Points are estimated based
on the efforts and complexity.
 2)No correlation with skills and
experience of the estimator .
 3)Universal measurement across
the whole team & not depend on
who’s implementing the story .
Time Based estimation
 1) The approach to measure the
amount of work that can be
completed by one person in 1hrs.
 2)It Underestimates the obstacles
they might face and consider only
the best case scenario.
 3) The work might be estimated
and completed by different
developers.

42. Fibonacci Series for story points
 The fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8,
13, 21, and so on.
 Teams use this sequence, rather than a linear 1 – 10 as it forces them to provide a relative
estimate. Easier to ask ‘is that a 5 or an 8?’ than ‘is that a 6 or a 7?’.
 The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in
estimating larger items.
 The information that we obtain out of estimation grows much slower than the
precision of estimation. In fact it grows as a logarithmic function. This is the reason
for the higher uncertainty for larger items.
 because they grow at about the same rate at which we humans can perceive meaningful
changes in magnitude

43.  The Cone of Uncertainty describes the evolution of
the amount of uncertainty during a project.
 Uncertainty not only decreases over time passing, but
it also diminishes its impact by risk management,
specifically by decision-making.
 At the beginning of a project, comparatively little is
known about the product or work results, and so
estimates are subject to large uncertainty. As more
research and development is done, more information is
learned about the project, and the uncertainty then
tends to decrease, reaching 0% when all residual
risk has been terminated or transferred.
 This usually happens by the end of the project i.e. by
transferring the responsibilities to a separate
maintenance group.
 The term Cone of Uncertainty is used in software
development where the technical and business
environments change very rapidly.
The cone of uncertainty

45. T-Shirt Sizing estimate
 A form of estimation that is often, although not
exclusively, used to size product backlog items
 T-shirt sizing is a way to practice relative sizing.
 Commonly used with T-shirt sizes: extra small,
small, medium, large, extra large, etc.

46.  A storyboard is a graphic organizer
that provides the viewer with a high-
level view of a project.
 In Agile software development,
a storyboard can help developers
quickly get a sense of what work
still needs to be completed.
 In Scrum software development,
the storyboard may be called a task
board.
Story Board /
Task Board-M&C

47. Burn Down Chart-M&C
A burn down chart is a graphical representation
of work left to do versus time.
The outstanding work (or backlog) is often on
the vertical axis, with time along the horizontal.
it is a run chart of outstanding work.
Progress on a Scrum project can be tracked by
means of a release burndown chart.
It is useful for predicting when all of the work
will be completed.
The horizontal axis of the sprint burndown
chart shows the sprints; the vertical
axis shows the amount of work remaining at the
start of each sprint.

48. Burn Up Chart-M&C
 Burn up chart shows how much work
has been completed.
 It is an effective tool for communicating
to the project stakeholders and clients how
the extra feature requests they are asking
for will affect the deadline, and at the
same time for reassuring them that good
progress is being made.
 In the simplest form of burn up chart
there are two lines on the chart:
 1) A total work line (the project scope
line)
 2) A work completed line
 Burn up charts are slightly more complex
to interpret than burn down charts, so will
often require some short explanation to
people not familiar with them.

49. Technical debt- Quality
 Technical debt (also known as design debt or
code debt) is a concept in software development
that reflects the implied cost of additional rework
caused by choosing an easy solution now instead
of using a better approach that would take
longer.
 Code that is not quite right may include many
types of issues. These issues may be related to
architecture, structure, duplication, test coverage,
comments and documentation, potential bugs,
complexity, code smells, coding practices and
style. All these types of issues incur technical
debt because they have a negative impact on
productivity.

50. SCRUM Quick flash
3 Roles: 1)Product Owner 2) Scrum Master 3) Scrum Team/Dev Team
4 Cermonies/Events:
a) Sprint Planning
b) Daily Scrum
c) Sprint Review
d) Sprint retrospective
3 Artifacts : 1)Product Backlog 2)Sprint Backlog 3)Product Increment
3Pillars : 1) Transparency 2) Inspection 3) Adaptation
5 Values : 1) Openness 2) commitment 3)Courage 4) Focus 5) Respect

51. MoSCoW Analysis – Prioritization of the
Product Backlog
 The MoSCoW method is a
prioritization technique used in
management, business analysis,
project management, and software
development to reach a common
understanding with stakeholders on
the importance they place on the
delivery of each requirement.
 MosCoW is a way determining the
importance of requirements for
a project

52. Happy Scrumming