Introduction to Scrum bases, how the Scrum was developed, why the Scrum is widely used, what the Scrum framework defines

1. Intro to Scrum
Why, What and How

2. Definition of Scrum
on Dictionary.com
Noun
1. a Rugby play in which, typically, three members of each team line up
opposite one another with a group of two and a group of three players
behind them, making an eight-person, three-two-three formation on
each side; the ball is then rolled between the opposing front lines, the
players of which stand with arms around a teammate's waist, meeting
the opponent shoulder to shoulder, and attempt to kick the ball
backward to a teammate.
2.British. a place or situation of confusion and racket; hubbub.
Verb (used without object), scrummed, scrumming.
3.to engage in a scrum.

3. Science behind Scrum
• Fight for possession - Video
– Your team is the Red team
– Ball is your scope of work
– Green team is the reality (disruptions,
impediments, the unknown and unexpected, etc.)

4. Initial idea of Scrum
“ The “relay race” approach to product
development may conflict with the goals of
maximum speed and flexibility. Instead a holistic
or “rugby” approach - where a team tries to go
the distance as a unit, passing the ball back and
forth - may better serve today’s competitive
requirements.”
Hirotaka Takeuchi and Ikujiro Nonaka, “The New
New Product Development Game”, Harvard
Business Review, January 1986.

5. 6 Characteristics of Leading Companies
• Built-in Stability
• Self-organizing project teams
• Overlapping development phases
• “Multilearning”
• Subtle control
• Organizational transfer of learning
Source: “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka

6. Approaches to phases of development
• Under the old approach, a product development process moved like a relay race, with one group of
functional specialists passing the baton to the next group. The project went sequentially from phase to
phase: concept development, feasibility testing, product design, development process, pilot production,
and final production.
Under this method, functions were specialized and segmented: the marketing people examined customer
needs and perceptions in developing product concepts; the R&D engineers selected the appropriate
design; the production engineers put it into shape; and other functional specialists carried the baton at
different stages of the race.
Source: “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka

7. Business Case
• The Honda City project team, whose members’ average age was 27, had these instructions from
management: to develop “the kind of car that the youth segment would like to drive.”
• The team was asked to develop a car with two competitive features for the youth segment: efficiency in
resources and fuel, and uncompromising quality at a low price.
• They started with the scaled-down version of Honda’s best-selling Civic model, but made a totally new
concept. Convinced that an evolution toward a “machine minimum, human maximum” concept was
inevitable, they challenged the prevailing idea that a car should be long and low and designed a “short and
tall” car.
Source: “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka

8. History of “Scrum”
• Takeuchi and Nonaka, two acknowledged management thinkers and accomplished professors, wrote a groundbreaking paper ‘The New New
Product Development Game’ and published it in Harvard Business Review in 1986. With the term ‘Scrum’ Nonaka and Takeuchi referred to the
game of rugby to stress the importance of teams and some analogies between a team sport like rugby and being successful in the game of new
product development. The research described in their paper showed that outstanding performance in the development of new, complex products is
achieved when teams, as small and self-organizing units of people, are fed with objectives, not with tasks. The best teams are those that are given
direction within which they have room to devise their own tactics on how to best head towards their joint objective. Teams require autonomy to
achieve excellence.
The Scrum framework for software development implements the principles described in this paper for developing and sustaining complex software
products.
• Based on this paper Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90’s. They codified Scrum in 1995 in order to
present it at the Oopsla conference in Austin, Texas (US) and published the paper “SCRUM Software Development Process”.
While in the process of developing and using early versions of Scrum, Ken asked Professor Babatunde A. Ogunnaike Tunde, a famous process control
research engineer, to look at software development processes. Tunde investigated several commercial software-development methodologies to
conclude that the waterfall and predictive process is not a good fit for the work of software development. He confirmed the empirical approach of
Scrum to be the preferred process.
Empiricism is used for complex work where more is unknown than is known and predictions have little value given a high rate of change and
uncertainty.
Scrum was first tried and refined at Individual, Inc., Fidelity Investments, and IDX (now GE Medical).
• February 2001 - Jeff and Ken were amongst the 17 software development leaders creating the Manifesto for Agile Software Development.
Following the Agile Manifesto, the Agile Alliance was founded with Ken Schwaber being its first chairman.
• 2001 - much inspired by Kent Beck, Ken Schwaber co-authored the first book on Scrum with Mike Beedle, Agile Software Development with Scrum.
• 2002 - Ken Schwaber founded the Scrum Alliance with Mike Cohn and Esther Derby, with Ken chairing the organization. In the years to follow the
highly successful Certified Scrum Master programs and its derivatives were created and launched.
• 2006 - Jeff Sutherland created his own company, Scrum.inc, while continuing to offer and teach the Certified Scrum courses.
• 2009 - Ken left the Scrum Alliance, and founded Scrum.org to further improve the quality and effectiveness of Scrum, mainly through the
Professional Scrum series.
• 2010 - With the first publication of the Scrum Guide, and its incremental updates in 2011 and 2013, Jeff and Ken established the globally recognized
body of knowledge of Scrum.

9. Simple
Anarchy
Technology
Requirements
Far from
Agreement
Close to
Agreement
Closeto
Certainty
Farfrom
Certainty
Project Noise Level
Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with
Scrum by Ken Schwaber and Mike Beedle.
Empiricism is used for complex work where
more is unknown than is known and
predictions have little value given a high rate
of change and uncertainty.
Software development is proven to be
complex work so the empirical approach of
Scrum should be the preferred process,
according to research of professor Tunde.

10. Definition of Agile
Full Definition of AGILE
1: marked by ready ability to move with
quick easy grace <an agile dancer>
2: having a quick resourceful and
adaptable character <an agile mind>
- Merriam-Webster Dictionary

11. Agile Manifesto
Process and tools
Individuals and
interactions
over
Following a plan
Responding to
change
over
Comprehensive
documentation
Working software over
Contract negotiation
Customer
collaboration
over
Source: http://agilemanifesto.org/

13. 12 Principles of Agile Manifesto
1. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work
together daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of
progress.
8. Agile processes promote sustainable
development. The sponsors, developers, and users
should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence
and good design enhances agility.
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
11. The best architectures, requirements, and designs
emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Source: http://agilemanifesto.org/

14. Scrum in 100 words or less
• Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to
determine the best way to deliver the highest priority
features.
• The whole software development lifecycle (SDLC) is done
in one Sprint.
• Every two weeks to a month anyone can see real working
software and decide to release it as is or continue to
enhance it for another sprint.

15. Scrum is
• Easy to understand
• Human focused
• Value focused
• About learning
• About people

16. Scrum is NOT
• Undisciplined
• Project Management
• Methodology
• Trivial to implement
• Process focused
• Productivity focused
• The final goal
• About tools

17. Scrum has been used by:
• Microsoft
• Yahoo
• Google
• Electronic Arts
• High Moon Studios
• Lockheed Martin
• Philips
• Siemens
• Nokia
• Capital One
• BBC
• Intuit
• Nielsen Media
• First American Real Estate
• BMC Software
• Ipswitch
• John Deere
• Lexis Nexis
• Sabre
• Salesforce.com
• Time Warner
• Turner Broadcasting
• Oce
Source: https://www.mountaingoatsoftware.com/agile/scrum/a-reusable-scrum-presentation

18. Scrum has been used for:
Commercial software
In-house development
Contract development
Fixed-price projects
Financial applications
ISO 9001-certified applications
Embedded systems
24x7 systems with 99.999%
uptime requirements
Video game development
FDA-approved, life-critical
systems
Satellite-control software
Websites
Handheld software
Mobile phones
Network switching applications
ISV applications
Some of the largest applications
in use
Source: https://www.mountaingoatsoftware.com/agile/scrum/a-reusable-scrum-presentation

19. Scrum in other industries
Scrum is used successfully
in:
Army – example General McChrystal
Education
Government
Venture capitalism
Automotive design
Retail
Sales
Marketing
Management
Product design
Design
…

20. Why Scrum?
“Prediction is very difficult, especially about the
future.”
- Niels Bohr, Danish physicist who made foundational contributions to understanding atomic structure and quantum theory,
for which he received the Nobel Prize in Physics in 1922.
Traditional processes (e.g. Waterfall) depend on
prediction over long time scales.
They guess wrong what is needed.
They miss the mark about when it will be
done.

21. What is Scrum?
• Scrum is a time boxed, iterative approach to software delivery
that builds software incrementally from the start of the
project, instead of trying to deliver it all at once near the end
of project.
• Scrum lays out the vision and then nurtures the project
resources to do the best possible to achieve the plan and
fulfill the vision.
• Scrum is the heart of possible.
• Scrum’s heart is self-organization.

22. How does Scrum work?
• Frequent inspection and adaption
• Emergence of requirement, technologies and
team’s capabilities.
• Self-organization and adaption in response to
what emerges using feedback
• Incremental emergence
• Dealing with reality, not internal artifacts
• Mutual coordination

23. Scrum Sprint Cycle
Scrum Framework

24. Scrum Framework
•3 ROLES
•4 CEREMONIES
•4 ARTIFACTS
 Product Owner
 Scrum Master
 Development Team
 Sprint Planning
 Daily Scrum Meeting
 Sprint Review
 Sprint Retrospective
 Backlog Refinement
(ExGrooming)???
 Product Backlog
 Sprint Backlog
 Increment
 Burndown Chart

25. Product Owner
• One person
• Maximizes ROI – Responsible for value and ROI
• Defines the product features based on the Product Vision
• Ensures that one set of requirements drives the
development and that there is no confusion from multiple
bosses, different opinions and interference from outside.
• “The Answer Man” to the Development Team during the
sprint.
• Prioritizes features according to business value
• Adjusts features and priorities every iteration, if needed.
• Decides which PBIs are releasable.
• Accepts or rejects work

26. Product Vision
Every Scrum project needs a product vision that acts as the project’s true north, sets the
direction and guides the Scrum team. It is the overarching goal everyone must share – Product
Owner, Scrum Master, team, management, customers and other stakeholders.
“The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog.
The vision describes why the project is being undertaken and what the desired end state is.” - Ken
Schwaber 2004
“Vision is the art of seeing things invisible.” - Jonathan Swift
It captures the essence of the product – the critical information we must know to develop and
launch a winning product.
Developing an effective product vision entails carefully answering the following questions:
1. Who is going to buy the product?
2. Who is the target customer?
3. Which customer needs will the product address?
4. Which product attributes are critical to satisfy the needs selected, and therefore for the
success of the product?
5. How does the product compare against existing products, both from competitors and the
same company?
6. What are the product’s unique selling points?
7. What is the target timeframe and budget to develop and launch the product?
Source: https://www.scrumalliance.org/community/articles/2009/january/the-product-vision

27. Scrum Master
• Team’s servant leader
• Responsible for enacting Scrum values and
practices
• Sustains culture and environment to optimize ROI
• Removes obstacles to progress (impediments)
• Ensures that the team is fully functional and
productive
• Enables close cooperation across all roles and
functions
• Shields the team from internal interferences
• May not direct team, nor tell them what to do
• Organizes Sprint Planning
• Facilitates Daily Scrum Meetings

28. Development Team
Superheroes, because:
1. Superheroes never give up
2. Superheroes get the job done
3. Superheroes are the best at that they do
4. Superheroes have a crystal clear purpose
5. Superheroes' goal is not to be perfect, but to pursuit perfection
6. Superheroes help others
7. Superheroes can do it by themselves, but they're more powerful
in teams
8. Superheroes' real strength comes not from their powers, but from
their character
9. Superheroes achieve great feats
10. Superheroes don't seek glory, but they receive it anyway

29. Development Team
• Estimates, selects and develops work items
• Team is cross-functional with all talents
necessary to build a potentially shippable
increment of product
• Manage time-boxed development iteration to
its forecast
• Stable team membership over time
• Delivers a potentially shippable increment of
product to the Product Owner once per sprint

30. Scrum Framework
•3 ROLES
•4 CEREMONIES
•4 ARTIFACTS
 Product Owner
 Scrum Master
 Development Team
 Sprint Planning
 Daily Scrum Meeting
 Sprint Review
 Sprint Retrospective
 (Backlog Refinement -
exGrooming)???
 Product Backlog
 Sprint Backlog
 Increment
 Burndown Chart

31. Sprint Planning
• Two parts (1-4 hours, depending on the length of the sprint)
• Product Owner must be prepared with adequate Product
Backlog, if not… go to the beach!!!
• Team selects the items from the Product Backlog they can
commit to complete.
• Team agrees on how to implement the product functionality
into the product increment in the next Sprint, thus creating a
Sprint Backlog
• Team defines Sprint Goal
• Estimates may be revised during the meeting
• High-level design is considered and development team
defines PBI implementation strategy

32. Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint goal
(design)
• Create sprint backlog (tasks) from
product backlog items (user
stories / features)
• (Re)Estimate sprint backlog
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product

33. Product Backlog into Sprint Backlog
Example
As a vacation planner, I
want to see photos of the
hotels.
Code the middle tier (8)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)

34. Sprint Goal
• The Team commits to the Team’s Sprint Goal!
• Sprint Goal can be any coherence that causes
the Development Team to work together
rather than on separate initiatives.
• The Sprint Goal gives the Development Team
some flexibility regarding the functionality
implemented within the sprint.

35. Sprint Goal Examples
Database Application
Make the application run on SQL
Server in addition to Oracle.
Financial services
Support more technical indicators
than company ABC with real-time,
streaming data.
Life Sciences
Support features necessary for
population genetics studies.

36. Daily Scrum Meeting
• DAILY!!!
• 15min
• Stand up!
• It helps avoid unnecessary meetings
• Not for problem solving (focus is on visibility)
• Whole world is invited, but only team members can talk (Development
Team, Scrum Master and Product Owner)
• Everyone answers 3 question:
1. What did I do yesterday? (…that helped Development Team meet the Sprint
Goal?)
2. What will I do today? (…to help Development Team reach the Sprint Goal?)
3. Do I have anything in my way? (Do I see any impediments that prevent me
of Development Team to reach the Sprint Goal?)
• These are not status for the Scrum Master. They are commitments in front
of peers

37. Sprint Review
• Team presents what it accomplished during the Sprint.
• “Are we happy with the overall results so far?”
• Presentation is in the form of demo of new features, fixed defects and/or
underlying software architecture.
• Presented on the equipment where it was developed and tested
• Presented by Development Team for Product Owner, other stakeholders
and end-users
• Only DONE items are presented. Definition of Done (DoD) is defined by
the team and it represents the reporting tool about what items are ready
to potentially be shipped. It can represent the steps for each items to go
through (design, dev, code review, unit test, functional test, regression
test, staging, deployment test, etc.), things they need to include (technical
description, user manual, release note, etc.),…
• Everyone is invited
• Max 1 hour DEMO presentation
• NO POWER POINT!!!

38. Sprint Retrospective
• We’re not “Scrumming” without the process improvement each Sprint.
• Done after every Sprint
• Whole team participate:
– Development Team
– Scrum Master
– Product Owner (2 schools of thought)
• Inspect how the last Sprint went in regards to people, relationships, process and
tools.
• Whole team gathers and discusses what they would like to:
– Start doing
– Stop doing
– Continue doing
• Identify and order the major items that went well and potential improvements.
• As a conclusion, Action plan is made to implement the wanted changes of highest
priority and to continuously repeat the wanted existing once.

39. Product Backlog Refinement (ExGrooming)
• Most of the Product Backlog should be prepared before Sprint
planning.
• Only READY PBIs can be candidates for Sprint Planning. PBI is Ready
if it has enough details so that all team members understand what
it is and they can all estimate it.
• Unprepared Product Backlog makes for the terrible meetings. It can
demotivate and slow down the entire Team.
• PBIs are prepared in the Product Backlog Refinement meeting. This
meeting can be scheduled weekly or more frequently where
needed.
• It is Product Owner’s responsibility to present Product Backlog with
enabling specifications.
• The Development Team estimates the PBIs.
• Product Backlog Refinement is scheduled in advance – not on an
interrupt bases.

40. Planning Poker - How it’s done?

41. Planning Poker
• Wideband Delphi estimation technique that was
adjusted.
• It gives the visibility of differences.
• Drives to consensus
• Breaks down linear thinking
• Everybody participates
• It avoids “coloring” of estimates by few key
members of Team (architects, team lead, etc.)
• It speeds up estimation process
Source: https://www.crisp.se/bocker-och-produkter/planning-poker

42. Scrum Framework
•3 ROLES
•4 CEREMONIES
•4 ARTIFACTS
 Product Owner
 Scrum Master
 Development Team
 Sprint Planning
 Daily Scrum Meeting
 Sprint Review
 Sprint Retrospective
 (Backlog Refinement -
exGrooming)
 Product Backlog
 Sprint Backlog
 Increment
 Burndown Chart

43. Product Backlog
• A good product backlog supports
communication between the Development
Team, Product Owner and other stakeholders.
• Efficient communication happens face-to-face
– not in writing.
• The form of the Product Backlog Items can
support more or less structured
communication and therefore can have a BIG
impact on the team’s Velocity.

44. Product Backlog
• Product Backlog is a list of all types of requests: User Stories,
use cases, defects, enhancements and technical issues.
• PBIs are mostly in Customer’s space – what, not how!
• Product Owner is responsible for ordering PBIs, prioritizing
them.
• PBIs can be placeholders that are later defined as work.
• Emergent, ordered, estimated – not categorized
• Higher Product Backlog Items have more details and have
higher priority than lower once.
• One list per product, can be for multiple teams
• Maintained and posted visibly
• Derived from Business Plan, Marketing, Sales, Support,
Product Management and/or Vision Statement

45. Product Backlog

46. Sprint Backlog
• 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 is the set of Product Backlog Items selected for the sprint, plus a plan for delivery of
product increment and realizing the sprint goal.
• Individuals sign-up for the work of their own choosing!
• WORK IS NEVER ASSIGNED!
• This plan has enough details so that changes in progress can be understood in the Daily Scrum.
• The Development Team can modify the Sprint Backlog throughout the Sprint, where and if necessary.
• This emergence occurs as Development Team works through the plan and learns more about the work
needed to achieve Sprint Goal.
• ONLY Development Team can change its Sprint Backlog during the Sprint!
• As new work is required from the Product Backlog, the Development Team adds it to the Sprint Backlog. As
work from the Product Backlog is performed or completed, the estimated work remaining in Product
Backlog is updated.

47. No changes during Sprint!
• Plan sprint durations around how long you can
commit to keeping change out of the sprint
Change

48. Scrum Board

49. Product Increment
• The Increment or Potentially Shippable Increment
(PSI) is the sum of all the Product Backlog items
completed during the Sprint (and all previous
Sprints that haven’t yet been shipped). –
definition of the Release
• At the end of Sprint the Increment must be
complete, according to the Scrum team’s
Definition of Done (DoD), and in a usable form
(shippable) regardless if the Product Owner
decides to actually release it or not.

50. Burn down Chart
• It is wasteful to track time consumed completing a
User Story or doing a Task.
• Time records are waste of time!
• Focus should be on achieving the end date (end of
Sprint) while reaching the Sprint Goal.
• Burn down Charts are the central “Project
Management” tool.
• Focus is on delivery!
• Cost management comes from estimations.
• Velocity estimations (Capacity) comes from Burn down
Chart.

51. Burn down Chart
• We shouldn’t care where we have been, since the time
spent is the time we can never recover. We should care
about the time we will spend in the future, which is
based on some form of estimate.
• These estimates should be good enough to give
Product Owner comfort that she/he can count on
Development Team’s forecast.
• Over time Development Team becomes better and
better at predicting. Burn down chart is also used as a
training tool for the team and Scrum Master’s tool for
inspection whether the Team’s learning is on track.

52. Burn down Chart - Examples

53. Time boxing
• Sprint is the main unit of time boxing.
• Sprint is a time for the Development Team to work undisturbed.
• Having fixed time boxes establishes rhythm which helps set
expectations over time – not only for the team but for the
stakeholders, Product Owner and Management as well.
• If Sprint lasts longer than expected, stakeholders and Product
Owner might suspect the team is guessing its work.
• It also helps the team to estimate their work better. Sprint when
time boxed gives them a reference point, so that they can learn and
improve their estimates and team capacity estimate over time.
• Time boxing is also used for all Scrum Ceremonies so that the time
is not wasted, but rather to get the Team to be concise and on
point. It takes several Sprints for the Team to fit into assigned Time
boxes and use this time with quality.

54. Scalability of Scrum
• Typical individual team is 7 ± 2 people
– Scalability comes from team of teams
• Factors in scaling
– Type of application
– Team size
– Team dispersion
– Project duration
• Scrum has been used on multiple 500+
person projects

55. Scalability of Scrum
• There are 2 two leading frameworks used for
scaling Agile:
– Scaled Agile Framework – SAF
– Large Scale Scrum – LeSS
• Both of them are using some form of Scrum of
Scrums model

56. The power of MOTIVATION
Online training - Introduction to Scrum: http://www.scrumtrainingseries.com/