Scrum overview - Animated - Scott Emery 2014

Date: July 2014
Scott Emery, CSM – Sr. Health Intelligence Analyst,
Providence Health & Services
Scrum Overview
What is Scrum and why would you use it?
Animated Version
This PowerPoint does not view properly
on SlideShare but must be downloaded

7/31/2014Scrum Overview 2014 – Scott Emery, CSM 2
scrum
skrəm/
Noun RUGBY
1.an ordered formation of
players, used to restart
play,…
scrum
skrəm/
Noun SOFTWARE DEVELOPMENT
1.A framework for managing
product development in
iterations, or sprints…

Do you want a long-winded definition of Scrum?
We can do that…
But one of the founding principles of Scrum could be
stated,
“Most people don’t like to read long,
tedious & very detailed documents.”
So instead, try this:

Scrum is an agile software development framework for managing
product development in iterations, or sprints.
Scrum enables teams to self-organize by encouraging close online
collaboration of all team members and daily communication with all
team members and disciplines in the project.
A key principle of Scrum is its recognition that during a project
the customers can change their minds about what they want and need,
and that unpredicted challenges cannot be easily addressed in a
traditional manner.
Scrum accepts that such problems cannot be fully defined, focusing
instead on maximizing the team's ability to deliver quickly and
respond to emerging requirements.
Small Chunks of Work
Improve over time
15-minute daily meetings
customers don’t know what they want until they actually see it
Fixing problems before they get really big

The traditional software development project management framework
is called Waterfall.
Requirements
Development
Testing
Design
Deploy
It’s called Waterfall because after each
functional team completes their work,
they “throw it over the edge” to the next
functional team. In Waterfall, change is
generally considered to
be a problem stemming
from poor planning.
Ouch!
Didn’t see that
one coming!

The first problem with Waterfall is Built-in Communication Gaps.
Requirements
Development
Testing
Design
Deploy
• Each time work passes between these functional
teams there is a high probability some of the
information won’t make the transition.
Communication Gaps
More Gaps
More Gaps
More Gaps
Each stage of the Waterfall
results in a detailed document
that has to be consumed by the
next team.
The problem is, the next team
always has a tight deadline and
feels pressure to “Get to work”
rather than spend time reading.
“Oops, I didn’t
document it correctly”
“Oh, I didn’t read that”

Requirements
Development
Testing
Design
Deploy
The second problem is that Risk Accumulates over Time.
• Restated as a Rule: The longer the time between project start
and delivery of software to the customer, the greater the risk.
• Unfortunately, waterfall projects take a relatively
LONG TIME before they deliver working software.
1-2 years
Very
Expensive
Problems!

Requirements
Development
Testing
Design
Deploy
i.e., At the 80% mark when
you have run out of time
and money, you must pay
more of both in order to
get anything at all.
Waterfall is a
“risk-accumulation”
model with a
hostage-taking
situation near the end.
If you cut the project off
before 100% of the
features are 100% done,
you get nothing.
That’s because 100% of
the features are 80% done.
Deploy
The Ransom: You have to
pony up more time and
money if you actually want
the product delivered.

Requirements
Design
Develop
Test
Demo & Deploy
Evaluate & Re-prioritize
It starts with the same
basic framework as
Waterfall:
But it shortens the
time frame…
Bites off smaller
chunks…
Adds a step…
Then its “Wash,
Rinse and Repeat”
for the rest of the
To Do list.
2 Years2 Weeks
2
3
1
4
5
6
7
8
9
10
12
13
14
15
16
17
18
19
20
11
To Do
5
6
4
8
9
7
Agile is a refinement of the waterfall process.
n
n
n


Gather Requirements
Design
Develop
Test
Deploy & Demo
Gather Requirements
Design
Develop
Test
Deploy & Demo
Gather Requirements
Design
Develop
Test
Deploy & Demo
Gather Requirements
Design
Develop
Test
Deploy & Demo
Each feature is fully developed and tested within
a Sprint, and is demoed & delivered right away.
1st most important
requirement
2nd most important
requirement
3rd most important
requirement
N most important
requirement
And with each delivery of
functional software,
RISK ACTUALLY DECLINES.And you start with the MOST important features.
Because problems are
quickly identified in the
Demo session…
…and can be immediately
fixed in the next sprint.
In Agile, Change is
welcomed as a way to
catch mistakes early,
before they become
really expensive to fix!Change?
Change?
Change?

Scrum is a specific “Flavor” of Agile.
Scrum’s greatest strength is in it’s focus on “Tips and tricks” that have proven to be
very effective at helping development teams be more productive.
Other Agile “Flavors” include:
• XP (Extreme Programming)
• Kanban (derived from Toyota)
• Feature-Driven Development
This development team focus is also Scrum’s greatest weakness: It doesn’t explain
how to gather requirements.
• It only defines how requirements need to be presented to the development team
in order to eliminate confusion.
• Some trainers and practitioners (e.g., Mark Layton and Platinum Edge) have
created expanded frameworks that include requirements gathering.

7/31/2014Scrum Overview 2014 – Scott Emery, CSM
2
3
4
5
6
7
8
9
10
N
1
Product
Backlog
The Product Owner meets with Stakeholders,
Business Analysts and Subject matter Experts
to develop a PRIORITIZED list of requirements
called a “Product Backlog”
In Scrum, requirements are grouped into
features, or “Stories.” A story is written from
an end-user perspective, so it is always tied
to actual user needs.
The Story is a one sentence description with
three parts:
1. The user
2. The feature
3. The benefit of the feature
Example: As a CFO I want to be able to see
daily admissions for each hospital and clinic so
I can manage performance in a timely manner.
A story is just a
reminder of the actual
requirement.
Each story has a list of
testable factors called
“Acceptance Criteria”
• Stats must be graphical
• Graphs must drill down
• Refreshed by noon
• Able to view hospitals
and clinics separately
• 12 months of history
QA tests each story
during the sprint, and
it is only Done when it
meets the Acceptance
Criteria.
12

To Do
2
3
4
5
6
7
8
9
10
N
Sprint
Backlog
1
Product
Backlog
The ScrumMaster holds a
Sprint Planning Meeting
with the Development
Team to determine how
many features (Stories)
the team can develop in
the sprint.
These stories become the
Sprint Backlog.
The Development Team plans and
estimates the work and Commits to
do the amount of work they believe
is possible in the sprint.
When the Development team
commits to the work, the sprint
is Frozen – no more work can be
added until the next sprint.
One of a
ScrumMaster’s main
responsibilities is to
make sure the sprint
stays frozen.
Sprint
Planning
meeting
Commit
Freeze
Backlog is just a fancy
term for a “To Do” list

DoneWorkingTo Do
2 - Kim
3 - Phil
4 - Kim
5 - Ray
6
7
8
9
10
N
----------------- Scrum Board -----------------
1 - Phil
Product
Backlog
Sprint
Planning
meeting
The Dev Team immediately
starts working on the
highest-priority items.
The major idea is to get
each story 100% done by
the end of the sprint.
Sprints are Time Boxed,
meaning every sprint has
the same duration,
Usually 1-4 weeks.
Sprints are never extended.
The team shows their
progress to the rest of
the world on a
scorecard called a
Burn Down Chart
The team tracks their
progress within the
team on a scorecard
called a
Scrum Board

DoneTo Do
2 - Kim
3 - Phil
4 - Kim
5 - Ray
6
7
8
9
10
N
-----------------Scrum Board ------------------
1 - Phil
Product
Backlog
Sprint
Planning
meeting
Working
The Scrum meeting
is a 15-min
coordination
meeting.
• What I did yesterday
• What I will do today
• What is giving me grief
During the scrum meeting,
Each Dev Team member tells
three things:
The team coordinates its activities each day with a Scrum Meeting.
Because the scrum
meeting is a team
coordination meeting,
instead of a reporting
meeting…
if things are going
smoothly enough, the
scrum master doesn’t
even have to be
present.

DoneTo Do
2 - Kim
3 - Phil
4 - Kim
5 - Ray
6
7
8
9
10
N
-----------------Scrum Board ------------------
1 - Phil
Product
Backlog
Sprint
Planning
meeting
Working
Sprint 3
Sprint 2
Sprint 1
Working
Software
Release 1
Sprint 5
Sprint 4
Release 2
Sprint 6
Sprint n
The Scrum Team is held
accountable to the
Product Owner and
other Stakeholders by a
Demo of working
software at the end of
each Sprint.
The Scrum Team meets at
the end of every sprint for
a Dev Team Retrospective
to determine how they
can work better in the
next sprint.
Each sprint ends with
additional FULLY
FUNCTIONAL software
that the customer has
seen and approved.
Releases are when the
software is published.
Customer
Demo
Retrospective

Working DoneTo Do
2 - Kim
3 - Phil
4 - Kim
5 - Ray
6
7
8
9
10
N
----------------- Scrum Board ------------------
1 - Phil
Product
Backlog
Sprint
Planning
meeting
Sprint 3
Sprint 2
Sprint 1
Working
Software
Release 1
Sprint 5
Sprint 4
Release 2
Sprint 6
During the Customer
Demo the Product Owner
Accepts or Rejects each
story.
If a story is rejected, a
Refactoring (rework) story
is put into the next sprint.
Stories need to be small
enough to fit into one Sprint.
If a story isn’t that small, it
needs to be split into 2 or
more smaller stories.
When the Dev Team plans
the sprint, they break
each story into tasks that
can be done by one
person in one day or less.
The tasks are discussed in
the Scrum meetings and
tracked on the board.
Customer
Demo
Retrospective





Re - 3
6b
6a
Task
Task

----------------- Scrum Board ------------------Sprint
Planning
meetings
Sprint 3
Sprint 2
Sprint 1
Working
Software
Release 1
Sprint 5
Sprint 4
Release 2
Sprint 6
6
7
8
9
10
N
Product
Backlog
Repeat with more sprints until project end
DoneTo Do
2 - Kim
3 - Phil
4 - Kim
5 - Ray
1 - Phil
Working
Sprint 1 Sprint 2
Sprint 3 Sprint n
Customer
Demos
Retrospectives

19
Sprint Planning
Working
Software
Release 2
Sprint 6
Customer Demo
Burn Down Chart
Daily Scrum
Dev Team
Retrospectiv
e
Sprint
1 - Phil
2 - Kip
3 - Lee
4 - Reg
5 - Bin
Sprint
Backlog
Scrum Board
Increment1
2
3
4
5
6
Product
Backlog
Project
Visibility
19

•7 people +/- 2
• Developers
• Quality Analysts
•Win/Lose as a team
•Self-directed, self optimizing
•Add Product Owner (PO)
•Add ScrumMaster (SM)
•Add Stakeholders

(PO)
•Decides What and When (i.e., the priority of each item)
•Not how much, because the PO is not doing the work
(Dev)
•How Much can be developed in one Sprint
•Commitment can’t be set from outside
(SM)
•In charge of the Process
•Works to optimize the process and the development
environment so the team can be as successful as possible.

• Wikipedia Scrum_(development)
• Scrum.org
• Agile Project Management for Dummies
• Scrum for Dummies (Nov 2014)

Aligns IT with the Business
• Business becomes part of the tactical team doing the work, not separate
Early measurable ROI
• Tangible product at the end of every Sprint
Daily visibility on project progress
• Control under Scrum is MUCH higher than under other methods
Ability to empirically forecast schedule and costs
• Early project performance can be intelligently extrapolated
Systematically supports changing business needs
• Re-evaluation and re-prioritization of objectives are built in
Early and continuous customer feedback
• This results in products that better meet customer needs

Reduces product and process waste
• Scrum uses a lot of lean principles
Focus is on adding quantifiable value
• Instead of administrative activities
ScrumMaster is a coach
• Instead of a “checkbox manager” (NOT, “Are you done with this yet?”)
Performance accountability is not ‘outsourced’ to the PM
• The people who are responsible for an action item are those who are
doing the work.
Less meetings
• And those are short and time boxed!
Builds empowered, motivated, self-organizing teams.

1. Commitment
• Scrum provides clear lines between what I did and did not commit to.
• Team members help form the goal rather than having someone else set the goals
for them.
• Team members have all the authority they need in order to meet their
commitments.
2. Focus
• Do your job. Focus all of your time and energy on meeting your commitments.
• Don’t worry about anything else.
3. Openness
• Scrum keeps everything about the project visible to everyone. In fact, it takes
visibility to new levels.
• “If you don’t air your dirty laundry, no one will wash it.”
4. Respect
• Our answers in aggregate are better than our answers as individuals.
• Team members respect each others experience and roles.
5. Courage
• Team members are expected to have the courage to commit, act, be open, and
expect respect.
• Scrum takes courage because it embraces change.

Scrum overview - Animated - Scott Emery 2014

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Ähnlich wie Scrum overview - Animated - Scott Emery 2014

Ähnlich wie Scrum overview - Animated - Scott Emery 2014 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Scrum overview - Animated - Scott Emery 2014

Hinweis der Redaktion