1. Introduction to Scrum

2. Agenda
Co
Common Issues in So t a e Development
o ssues Software e e op e t
What is Scrum?
The Scrum Framework
2

3. Introduction to Scrum
COMMON ISSUES IN
SOFTWARE DEVELOPMENT
3

4. Problems Many Companies Face
Time to market
Time-to-market for products is too long
Project failure rate is unacceptably high
Responding to change is difficult and costly
p g g y
Customer involvement is weak
Software quality is poor
Productivity is extremely low
Employee morale, drive and accountability is low
Widespread micromanagement is required
Employee turnover rates are too high
4

5. Common Issues From a
Business Standpoint
1. Our planning never yields precise results
2. Quality is poor and an increasing issue with our customers
3. Communication and visibility are lacking and I can’t set
y g
expectations with my team (the “users”)
4. I’m not able to make changes to scope easily without derailing
the ti
th entire project
j t
5. I don’t trust that my needs will be met
5

6. Common Issues From a
Development Standpoint
1.
1 Priorities and scope keep shifting based on the current
emergency and focus is totally lost
2. Unrealistic deadlines dictate poor architecture and design, as
well as implementation choices
3. Production support issues pull developers away from new
project work and timely enhancements to our product suite
(too many balls in the air)
4. Poor historical decisions are being paid for now in the way we
write code, rollout products, maintain systems, etc.
5. I don’t trust that my needs will be met
6

7. Working on the
Wrong Priorities is a Waste
Features and functions used in a typical system
Sometimes
Rarely
16%
19%
Often or always
used: 20%
Never
Often
45%
13%
Always
7% Rarely
R l or never
used: 64%
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
7

8. The Multi-Tasking Myth
Multi Tasking
Even adding a single project to your workload is profoundly debilitating by
Weinberg's calculation. You lose 20% of your time. By the time you add a
third project to the mix, nearly half your time is wasted in task switching.
Quality Software Management: Systems Thinking by Gerald Weinberg
8

9. Process Control
Defined Process Control: Empirical Process Control:
• Every task must be completely • The empirical model of
and unambiguously understood process control provides and
• Inputs are completely and exercises control through
unambiguously defined frequent inspection and
adaptation
• When given a well-defined set of • for processes that are
inputs, the same outputs are
generated every time imperfectly defined
• and generate unpredictable
and unrepeatable outputs
Illusion f Control: Development organizations t i ll d f lt t a “d fi d
Ill i of C t l D l t i ti typically default to “defined
process control” based on an outdated notion of how software is built. Has
anyone heard the “building software is like building a house” metaphor?
9

10. What We Need
A way for customers to see and evaluate progress before its too
y p g
late
A process that gives stakeholders more visibility, early and often
A process that’s more agile and responsive t changes
th t’ il d i to h
A process that allows development teams to “own” their
commitments
A process that accepts change but has enough rigor to yield a
quality result
A process that helps us be much more predictable
We need more Trust!
10

11. Introduction to Scrum
WHAT IS SCRUM?
11

12. Scrum is
is…
S pe a e o
Simple framework
Disciplined approach
Commitment oriented
Commitment-oriented
Results-oriented
Collaborative effort
Empirical process
“Scrum is not a methodology – it is a pathway” (Ken
Schwaber) )
12

13. What Is Scrum Being Used For?
Large-scale enterprise software p j
g p projects
Consumer software products
US FDA-approved software for X-Rays, MRIs
High availability systems (99.9999% uptime)
Financial payment applications
Large database applications
Embedded systems
CMMi L Level 5 organizations
l i ti
Multi-location development
Sustaining and Maintenance Projects
Non-software projects
13

14. Scrum Shifts the Drivers
Traditional Project Scrum
The plan creates The vision creates
cost / schedule feature estimates
estimates
Features Fixed Cost Schedule
Value
Driven
Plan
Driven
Cost Schedule Estimated Features
14

15. Benefits of Scrum
Sc u a o s tea s o peop e de e op co p e
Scrum allows teams of people to develop complex
products in environments of uncertainty and change.
Scrum is a simple but powerful framework for teams
and customers to i
d t t inspect and adapt as th product i
t d d t the d t is
produced.
Scrum provides a high degree of clarity and
transparency to everyone involved – team, customer,
management, and others.
Scrum rapidly surfaces dysfunction, and enables
teams and organizations to continuously improve their
effectiveness.
effectiveness
15

16. Typical Results with Scrum
3rd Annual Survey: 2008 “The State of Agile Development” 2319 Completed Surveys
Conducted June-July 2008 By VersionOne 80 Countries Represented
16

17. Introduction to Scrum
THE SCRUM FRAMEWORK
17

18. 3 Facets of Scrum
Roles Artifacts Practices
(Who)
(Wh ) (What) (How)
Product Owner Product Sprint
Team Backlog Sprint Planning
S
Scrum Master Sprint Backlog Meeting
Potentially Daily Standup
Shippable Sprint Review
Product
Sprint
Sprint Retrospective
Burndown Chart
18

19. Overview of Scrum Framework
Roles
Artifacts & Practices
19

20. Role:
Product Owner
O st e so o
Owns the vision of what s ou d be p oduced to ac e e
at should produced achieve
business success
Manages ROI through prioritization and release plans
Gets input from customers, end-users, team,
managers, stakeholders, executives, industry experts
when crafting the vision
Turns input into a single list of what should be
p
produced, p
, prioritized based on business value and risk
Owns the Product Backlog
“The Product Owner’s focus is ROI. The
Product Owner directs the project,
sprint by sprint, to provide the greatest
sprint
ROI and value to the organization.”
20

21. Role:
Team
O s t e p oduct o and engineering process
Owns the production a d e g ee g p ocess
Cross-functional - it has all the skills to produce the
finished product
Self-organizing and self-managing - it is responsible
for making a commitment and managing itself to hit the
goals (or get as close as it can)
Authority to do whatever is necessary to meet it’s
commitment
The ideal team size in Scrum is 7 people +/- 2
“The Team is responsible for managing
itself and has the full authority to do
anything to meet the sprint goal within the
guidelines, standards, and conventions of
the organization and of Scrum.”
21

22. Role:
Scrum Master
A new leadership role
e eade s p o e
It can be played by an existing person (such as a
former Project Manager or team-member).
Serves the team
Helping remove any and all impediments that surface
Protects the team
Teaches and guides the team’s use of Scrum
Facilitates – doesn’t “manage” (direct) the team
“The Scrum Master is responsible for the
success of the project, and helps increase
the potential for success by helping the
Product Owner select the most valuable
backlog items and by helping the Team turn
that backlog into functionality.” 22

23. Practice:
Sprint
The tea works for a fixed pe od of time.
e team o s o ed period o t e
Sprints are typically 1-4 weeks in length. Some
recommend starting Scrum with 2-week Sprints.
Sprints occur one after another, without any down-time
between them. Working at a sustainable pace is very
important to avoid team burn out
burn-out.
Team and Product Owner decide the Sprint length in
advance.
23

24. Practice:
Sprint Scope
Time frame a d co
e a e and commitments do not c a ge
t e ts ot change
Do not adjust schedule—end date of Sprint is fixed
The team s commitment is for length of Sprint
team’s
Enables the team to make and keep commitments
Gives the team focus and stability during the Sprint
Trains Product Owner to clearly think through what is
on the Product Backlog
In special cases, Product Owner can direct the team to
terminate the Sprint prematurely and start a new one.
24

25. Practice:
Sprint Scope
Future work
utu e o
Product Owner can make any changes they want to
the Product Backlog before the start of the next Sprint.
Product Owner can add, remove, reorder, or change
backlog items.
Product Owner can also ask the team to re-implement
work that has already been completed.
25

26. Artifact:
Product Backlog
Single master list of features, functionality, and other
g y
work required
Prioritized based on business value and risk, in the
judgment of the Product Owner
Items at the top of the list will be completed by the team
first and should have more detail than lower priority items
Constantly being revised by the Product Owner, to
maximize the business success of the team’s efforts
Product Backlog Items vary in size (typically 2-3 people,
2-3 days).
26

27. Artifact:
Product Backlog Example
Title Status Priority Estimate Reference
Money Market Access (BMG) checking data into FMG
DW(5275) In Progress Critical 1.00 SCR 5275
Develop Sales Rep Dimension Critical
Product Create Cognos catalog subject area - Dividends In Progress Critical 30.00
Create Cognos catalog subject area - SAM In Progress Critical 30.00
Backlog Create Cognos catalog subject area - SAD In Progress Critical 30.00
Analyze Call Center Reporting High SCR 5276
Items Modify CARMA to maintain WFFD terms & conditions High 52.00 SCR 5271
2003 and 2004 AUM differences clean-up High 0.00 SCR 5166
Unknown Sponsor / Strategy in FMG DW for Managed Accounts High 0.00 SCR 5165
Priority
Create effective dating for Territory Maintenance High 215.00
Create territory overrides High 215.00
Populate FMG-DW with territory informationOrder High 215.00
Prepare for production readiness High 100.00
Administrator group access on Windows servers High
Sybase Upgrade - UAT In Progress High 5.00
Managed Account Suspension Item 2 - Copy Back High 0.00
MAPS: Error - Rep info missing from Rep-EOM-CD High
High-level
Document overall data flow for populating the D Sales Rep
dimension In Progress High 7.00
Design a Code dimension In Progress High 20.50
Design a CRM HQ Company dimension
Estimate
In Progress High 7.50
Design a CRM Company dimension In Progress High 7.50
Design a Channel dimension In Progress High 9.50
Design an integrated Territory dimension In Progress High 10.50
VAS/PowerBroker Medium
Husky and FTP100 Tech Refresh Medium
Update User Created SQL Process Low SCR 5271
27

28. User Stories
“…are p o ses for a o go g co e sat o s
a e promises o an ongoing conversations”
Mike Cohn’s User Story template:
“As a <Some Role>
I want <Some Business functionality>
So that <Some Business Value or Justification>
For Developers, the “I want” clause is what counts,
For P d t O
F Product Owners, the “so that” clause is what counts
th “ th t” l i h t t
28

29. Types of User Stories
Epic
High level may contain only 2 of 3 components of user story
As a <user role> I want an application, so <business justification>
Used as place holders to create product roadmap
Themes – in between
Story – I.N.V.E.S.T. criteria
Independent
Negotiable
Valuable
Estimable
Small
Testable

30. User Story Example
As Tim (tired morning pe so ), I want my usua
s (t ed o g person), a t y usual
Kwikoffee so that I can get to work and without rushing.
“Done” when
A simple cup can be ordered from the kiosk
Automated tests written for all UATs
User documentation written for new/modified
functionality
30

31. Definition of Done
Defined by bot t e Product O e a d t e Team
e ed both the oduct Owner and the ea
Everyone agrees on the definition of done
Goals
Deliver complete “slices” of the system
Iterate over robustness
Tools
Solid engineering practices
Solid engineering infrastructure
31

32. Practice:
Sprint Planning Meeting
Team se ects what it will co
ea selects at t commit to deliver by t e e d o
t de e the end of
the Sprint
Team creates a task-level plan for how they will deliver
Team creates an initial assignment of tasks
Team compares total estimated task hours with total
estimated available hours, to make sure the commitment
is reasonable
Everyone on the team takes part, regardless of role and
part
experience-level
32

33. Practice:
Sprint Planning Meeting
Product O e must not p essu e t e tea into
oduct Owner ust ot pressure the team to
committing to more than they think is doable.
Managers may initially be concerned that their team might
under-commit.
d it
Many teams are initially concerned about the perception
of the amount of work being completed so they over
completed, over-
commit.
In reality, most teams have the opposite problem: it may
y, pp p y
take them several Sprints to learn to not over-commit.
33

34. Practice:
Sprint Planning Meeting
Example o Agenda
a p e of ge da
1:00 – 1:30. Product Owner goes through the sprint
goal and summarizes product backlog.
1:30 – 3:00. Team breaks down items and estimates
time. Product Owner updates priorities as necessary.
3:00 – 4:00. Team selects the backlog items to be
included in the sprint and makes commitment to
Product Owner.
34

35. Artifact:
Sprint Backlog
Co p ete st of tasks equ ed
Complete list o tas s required to meet the sprint goals
eet t e sp t goa s
and committed product backlog items
Tasks include detailed estimate created by the team
Team tracks effort remaining to complete each task
Constantly being revised by the Team, to maximize
achievement of the sprint goal
Tasks vary in size but no larger than 16 hours
35

36. Artifact:
Sprint Backlog Example
Detail
Backlog Item / Defect Task Owner Status Estimate Done To Do
Complete development of Office Confirm business rules Zigler, Al,Carter, Tammy Checked Out 4.00 3.50 2.00
Merge screens Update Search results integration tests Minor, Brian 4.00 4.00
Complete b i
C l t business rule validation
l lid ti Grayson, John
G J h 5.00
5 00 5.00
5 00
Review business rule validation Zigler, Al,Minor, Brian,Grayson, John,Carter Checked Out 5.00 2.00 3.00
Review business rules with PO Zigler, Al,Carter, Tammy Done 2.00 1.00 2.00
Backlog Develop Onyx table update Grayson, John Checked Out 6.00 2.00 4.00
Items Add integration tests for Office merging
Procedure test script
Grayson, John
Grayson, John
6.00
6.00
6.00
6.00
Peer review Minor, Brian,Dupont, Jason,Grayson, John 3.00 3.00
Review database changes Grayson, John Lin
Grayson John,Lin, Kim Done 1.00
1 00 1.00
1 00 0.00
0 00
Add Effective date - logical/physical models Lin, Kim 1.00 1.00
Add Effective date - implementation Lin, Kim 1.00 1.00
Update caliber Lemke, Linda 1.00 1.00
Tasks Review requirements - Onyx batch impacts/bShavasi, Sudhir Checked Out 2.00 2.00 0.00
Review requirements - Onyx batch impacts/bZigler, Al,Carter, Tammy,Shavasi, Sudhir Checked Out 3.00 1.00 2.00
Update test scripts Shavasi, Sudhir 3.00 3.00
p
Review test scripts Zigler, Al,Lemke, Linda,Carter, Tammy,ShavChecked Out
g , , , , , y, 4.00 5.00 2.00
Test data prep Shavasi, Sudhir 6.00 3.00 3.00
Execute component testing Shavasi, Sudhir 16.00 16.00
Issue resolution Minor, Brian,Grayson, John,Shavasi, Sudhir 12.00 12.00
Environment Build Create list of database for Rlse 1.0 Lin, Kim Done 1.00 1.00 0.00
Review list of Release 1.0 changes Minor, Brian,Lemke, Linda,Grayson, John,Lin, Kim,Carter, Tammy 5.00 2.00 4.00
Re-apply Release 1.0 changes - DEV Lin, Kim 4.00 1.00 3.00
Implementation Release 1.0 in local FMG Van Camp, Fred,Lin, Kim 2.00 2.00
User Training Manual Define scope, audience, and deliverables Lemke, Linda Checked Out 4.00 1.50 4.00
Document approach Lemke, Linda Checked Out 6.00 6.00
Draft Format of Manual Lemke, Linda 6.00 6.00
Draft Content Lemke, Linda 10.00 10.00
Review approach with product owners Lemke, Linda 4.00 4.00
Review & Update content with product owne Lemke, Linda 3.00 3.00
36

37. Practice:
Daily Standup
A short meeting da y to update eac ot e o p og ess
s o t eet g daily each other on progress
and surface impediments
Strictly time-boxed to 15 minutes
3 questions: what was done since last meeting, what will
be done by next meeting, and any issues/impediments
Scrum Master notes issues/impediments, and afterwards
helps resolve them
Others can attend the meeting if the team invites them,
them
but they do not speak. This meeting is not for monitoring
the team.
37

38. Artifact:
Burndown & Burnup Charts
Each day, the team updates simple c a ts that show
ac t e tea s p e charts t at s o
progress towards their Sprint goal.
The Burndown Chart graphs the total hours left for all
tasks.
t k
The Burnup Chart graphs the total number of backlog
items completed in the Sprint
Sprint.
These charts enable the team to successfully self-
manage and deliver what they committed to by the end of
g y y
the Sprint.
38

39. Artifact:
Burndown & Burnup Charts Example
Agile V Scorecard
39

40. Artifact:
Potentially Shippable Product
The goa for t e tea is to complete 100% o what t ey
e goal o the team s co p ete 00% of at they
committed to, ideally an increment of Potentially
Shippable Product at the end of each Sprint.
For ft
F software, this means f
thi functionality that has been
ti lit th t h b
designed, fully implemented, and fully tested, with no
major defects.
j
Few teams can produce Potentially Shippable Product
from Sprint 1, but each Sprint they work to get closer to
this
thi goal.
l
40

41. Practice:
Sprint Review (Demo)
Performed at t e e d o eac Sp t
e o ed the end of each Sprint
Product Owner, Team, Scrum Master, and Stakeholders
come together and see a demo of what the team has
produced
d d
Product Owner gathers feedback from everyone on the
ways to improve what has been built
Feedback is incorporated into the Product Backlog
41

42. Practice:
Sprint Retrospective
C t ca o co t uous p o e e t of team effectiveness
Critical for continuous improvement o tea e ect e ess
Method for identifying and addressing critical problems
Retrospective meeting requires the Team, Product
Owner, and Scrum Master
Focuses on 3 questions:
1. What worked well?
2. What needs improvement?
3. What action items do we implement in the next
sprint
42

43. Practice:
Sprint Retrospective
Example o Agenda
a p e of ge da
1:00 – 1:30. Review the commitment results for Sprint
1:30 – 2:00. Brainstorm everything that worked well
2:00 – 2:30. Brainstorm areas of improvement
2:30 – 3:00 Brainstorm action items to address areas
3:00.
of improvement
3:00 – 3:30. Select action items to implement next
sprint and commit to improve
43

44. Practice:
Sprint Retrospective
What went well?
All code was delivered ahead of schedule which helped in testing progress.
Code Review’s added
Review s
More continues development time
Requirements Update continued
Developers were able to take others tasks to help completion based on obstacles that came
What can we improve?
Revisit the meeting time of the huddle
g
Who closes stories/ tasks
Defines Goals in Advance
Requirements delay based on capacity and change in direction
Would like to continue to focus on collaboration between dev/req review
Requirements still key and needed. Difficult to determine focus split on documentation for
Too many stories
Difficult in switching views in VersionOne
Can we go to 4 week iteration?
Stories should not be added after the planning
Capacity concern with business partner time also. Might need to have multiple days to digest
and review with other business counter parts.
Action Items
Implement code reviews
Hold more design meetings, reviews with the Business Owner
Add Business owner tasks to VersionOne
44

45. Typical Project Lifecycle
Product /
Project Release A Release B
Planning Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Sprint Sprint Sprint Sprint Sprint Sprint
Planning Planning Planning Planning Planning Planning
Sprint Sprint Sprint Sprint Sprint Sprint
Review & Review & Review & Review & Review & Review &
Retro Retro Retro Retro Retro Retro
45

46. Introduction to Scrum
QUESTIONS
46