4. 0
1
2
3
4
5
6
7
8
9
10
0 1 2 3 4 5 6 7 8 9 10
ScrumFamiliarity
Current Process Effectiveness
Living
the dream
Things are just fine
without Scrum
Learning
and improving
We know what to do,
and we aren’t doing it
This hurts.
Help.
Where are you located on this graph?
5. TRUTHS ABOUT TEAM MOTIVATION
• People are most productive when they manage
themselves
• People take their commitments more seriously
than other people’s commitments for them
6. TRUTHS ABOUT TEAM PERFORMANCE
• Teams and people do their best work when
they aren’t interrupted
• Teams improve most when they solve their
own problems
• Face to Face communication is the most
productive way for teams to work together
• Teams are more productive than the same
number of individuals
7. Scrum in a Nutshell
Product Owner Scrum MasterDevelopment Team
Product Backlog Sprint Backlog
Daily Scrum
Increment
Scrum Team
Sprint
Sprint
Planning
Sprint
Review
Sprint
Retrospective
8. SCRUM: ORIGINATION
• The term Scrum is borrowed from a rugby play
where everyone stays focused on the ball
• A way to restart the game when the ball has
gone out of play
• Players connect together
as a team to compete for
the ball
9. SCRUM: THE FRAMEWORK
• Scrum is not a methodology
• Scrum is a tool used to create agility
• A framework within which people can address
complex problems and deliver products of the
highest possible value
10. Progress = Value Delivered (not effort expended)
Value = Potentially Deployable Software
• Requirements 90% Complete doesn’t deliver value
• Design 20% Complete doesn’t deliver value
The sole measure of progress is
“Potentially Deployable Software”
DELIVERING VALUE
11. MANAGEMENT NO LONGER NEEDS TO…
• Make commitments on behalf of the team
• Give direction to the team on how to meet
commitments
• Monitor teams progress to keep it on schedule
• Step in and fix problems if encountered
• Push team to work harder
• Decide work assignments and follow up to ensure
they are done
12. SCRUM LIFECYCLE
PLAN ANALYZE DESIGN CODE TEST RELEASEWaterfall:
Scrum:
P
L
A
N
ANALYZE
DESIGN
CODE
TEST
RELEASE
R
E
V
I
E
W
The same work, but
organized differently and
on fewer requirements,
Waste becomes visible and
can be quickly removed
Short, high
value
iterations that
deliver
functionality
14. PRODUCT OWNER
• Maximizes the Return on Investment
• Creates and orders Product Backlog
• Chooses what and when to release
• Single voice of the Customer
• Represents interests of stakeholders and
customers
15. PRODUCT BACKLOG
• A prioritized and complete list of desirements
• Potential features of the product
• Managed and groomed by Product Owner
• 10% of each sprint is spent discussing and
analyzing the backlog
• Single source of truth for what is planned for the product
• Public and available
16. PRODUCT BACKLOG ITEM
• A unit of deliverable work
• Contains clear acceptance criteria (criteria for
successful completion)
• May reference other artifacts like Specifications, Use
Cases, Wireframes, etc.
• Must be sized appropriately
• Small enough to be completed within a single Sprint
17. • PBIs are estimated and ordered for
about 3 Sprints at all times
• The current sprint is detailed
Broken into tasks
Very granular detail
• PBI’s for next 2 sprints are groomed
Understood by the entire team
Ordered
Estimated
User Stories with acceptance
criteria
Current Sprint
Next Sprint
Next, Next Sprint
ROLLING PRODUCT BACKLOG PROJECTION
18. USER STORIES – COMMON EXPRESSION OF PBIs
• High level desires of your product backlog are
incrementally decomposed into Detailed
requirements in the form of User Stories with
Acceptance Criteria
19. WHAT IS A USER STORY?
• Represents the basic unit of work for a Scrum team
• Cross-functional team members hold conversations to
flush out the detailed requirements
User Stories contain two main components:
1. Value Story: As a <Role> I Need <Goal> So That
<Reason>
2. Acceptance Criteria: Detailed requirements
(Functional, Non-Functional, Data, etc)
20. USER STORY EXAMPLE
Value Story:
As an online banking customer, I need the Overview page
in a 1024 x 768 screen resolution so that I can view more
information on the page.
Acceptance Criteria:
Given a PC that has the screen resolution set at 1024 x 768:
1. Customer sees the screen without any horizontal scroll bar
2. Customer sees the honeycomb background on the right and
left side of the page
3. Customer sees the page centered in the browser
21. THE DEVELOPMENT TEAM
• Cross-functional
• Jointly owns and commits to product backlog
items
• Ideally collocated, dedicated resources
• 6 members, +/- 3 (recommended not required)
• Highly collaborative
• Empowered and self-managed
• Everyone pitches in regardless of individual skill
or specialty
• Held accountable as a Unit
22. The Development Team should have every
competency it needs to deliver an
increment of “done” functionality
THE DEVELOPMENT TEAM
23. ESTIMATING
• Relative estimates are assigned to Product Backlog
items
• Fibonacci Set of Numbers (1,2,3,5,8,13 or 21)
• Medium size effort is 8
• Team votes on the relative size of the effort to do the
product backlog item
Discuss if large discrepancies in voting occur
If close, use the higher number
• Do not count on estimates by people who will not be
doing the work
24. FOUNDATION OF SCRUM
We all know what
Is going on.
Check your work
as you do it.
OK to change
tactical direction.
25. EMPIRICAL PROCESS
• Knowledge comes through experience
• Just in time planning and re-planning based on
frequent inspection
• Based on actuals rather than predictions
• Requires transparency
• Information is neither good nor bad only used to
make decisions
• Does not try to predict the future, only adapts to
the current
Scrum makes everything Transparent all the time so
that they can be quickly fixed
26. EMPIRICAL PROCESSES PLAN FREQUENTLY
P DPlanning Doing
Predictive Empirical
• All planning is
done at beginning
• Just-in-time
planning and re-
planning based on
frequent
inspection
P D P D P D P D P D
27. SPRINT
• Time-boxed at 30 days
• Contains the work necessary for the increment of
functionality and other events
• Functionality is potentially shippable
• Consistent durations
• Conducted in a vacuum, team is totally protected from
outside noise and interference
28. SPRINT PLANNING
• Time-boxed at 8 hours for 4 week sprints,
proportionately less for shorter Sprints
• Product Owner reviews top priority items with
Development Team
• Development Team determines how much they can do
and tasks necessary to complete items (Sprint Backlog)
• Sprint Goal is created
29. SPRINT GOALS
An objective to be met in the Sprint
Allows flexibility in delivering the increment of functionality
No changes may affect the Sprint goal during the Sprint
As team works, this goal is kept in mind
Each Daily Scrum assess the teams progress towards the goal
30. DEFINITION OF DONE
• Should include all steps necessary to make that PBI
potentially shippable
• Adhere to “done” every Sprint
• “Done” is for the entire product not just for one scrum
team’s increment
• All Scrum teams working on a product must have the
same definition of done
• Should be inspected at the end of each sprint
• Must be transparent
31. DONE MIGHT INCLUDE…
• Performance Testing
• Code Refactoring
• Integration with other teams (syncing, integration of
code, etc.)
• Release notes
• User Acceptance testing
• Regression testing
• Code reviews
32. INS and OUTS of SPRINT PLANNING
INPUTS OUTPUTS
• The Product Backlog
• The latest increment
• The number of hours the
Development Team has
available to work
(Capacity)
• Past performance of the
development team
(Velocity)
• Definition of Done
• The Sprint Goal
• Sprint Backlog
• 60% - 70% known
and accurate
• Some work emerges
later
33. SPRINT BACKLOG
• Created by Development Team during Sprint Planning
• Includes PBI’s committed to and tasks necessary to
complete each PBI selected
• Each task must be granular enough to be completed in
1 day or less
• Development team members sign up for tasks, they
aren't assigned
• Any development team member can add, delete or
change the Sprint backlog
• Work for Sprint emerges over time
• If work is unclear, update work remaining as more is
known and tasks are worked
34. CREATING THE SPRINT BACKLOG
Team selects a PBI
based on product
backlog order
Team identifies all
tasks necessary to
complete PBI
Team estimates
PBI via Story
Points
Add PBI to Sprint
Backlog
Negotiate what
can be delivered
from PBI or place
item back in
Product Backlog
Does PBI fit into
Sprint?
YES
NO
35. SPRINT AS A “DEAL”
The Development Team Clients
“Every Sprint you can have us
develop something new as
you see fit”
FLEXIBILITY
“We will leave you alone for
two weeks (or more) and will
not interfere while you work.”
STABILITY
36. SPRINT TASK BOARD
• A way to track the tasks necessary to complete
PBI’s
• Can be in a scrum room (physical, manual tracking),
can be virtual or both
37. The development team has decided how much it
can accomplish during the upcoming sprint. It now
sprints to accomplish the sprint goal as it sees fit,
adapting to the circumstances, technology and
organizational terrain as best it can
38. SPRINT REVIEW
• Time-boxed at 4 hours for 4 week sprints;
proportionately less for shorter Sprints
• Team demonstrates the increment of functionality
• Stakeholders provide feedback
• Product Increment and Product Backlog are inspected
and adapted
• Discuss what can be worked on next
39. SPRINT RETROSPECTIVE
• Time-boxed at 3 hours for 4 week sprints; proportionately
less for shorter Sprints
• Opportunity for Scrum team to inspect & adapt their
development process, tools and definition of done
• Develop plan for actionable improvements (to be
implemented in next Sprint)
40. EMPIRICAL PROCESSES REQUIRE COURAGE
Conversation will not take place unless people feel safe!
Goal
realization
Crucial
Conversation
Transparency
Inspection &
Adaptation
41. INCREMENT
• Working functionality
• Is potentially shippable and usable by
customer
• An output of the Sprint
• Must be DONE with no work remaining
42. SCRUM MASTER
• A servant leader
• Educates the Product Owner on their role
• Ensures the Scrum framework is followed
• Facilitates time boxed events
• Empowers team to self-organize
• Removes impediments
43. SCRUM MASTER
May Be May Not Be
• Anyone with the appropriate
servant-leader skills
• A member of the
Development team
• Fired by the team
• A Product Owner
• This is a direct conflict of
interest
45. DAILY SCRUM
• Time-boxed at 15 minutes
• Development Team is required to attend
• NOT a status meeting, team creates a plan for the
next 24 hours
• Three questions:
1. What have you accomplished?
2. What do you plan to accomplish?
3. What is impeding or slowing your progress?
How will the Development team achieve its forecast based on the
inspection?
46. BURNDOWN CHARTS
• Measurement for the Development team
• Used to see how they are progressing towards
the goal in the sprint
• May change abruptly when
New SBIs are added or removed during the
Sprint
Scope is renegotiated with the Product Owner
• Burndown charts can also be used by the
Product Owner to see how they are progressing
towards the release
47. 0
10
20
30
40
50
60
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day
10
Work Remaining
SPRINT BURNDOWN CHART
48. VELOCITY
• A measure of delivered value per sprint
• Used by the Product Owner to provide
forecasts
• Used by the Development Team to gauge how
much work to pull into the Sprint
49. VELOCITY FROM THE LAST RELEASE
0
5
10
15
20
25
30
35
40
45
50
1 2 3 4 5 6 7
Sprints
Velocity = 37
SP’s per sprint
Last Sprint = 47
50. SELF MANAGING TEAMS
• Who does what & when
• Who is needed on the team and not
• What customer input is needed and when
• When it needs help resolving Impediments
• What process improvements are needed
The Team Determines…
51. FEWER SPECIALISTS
• In a multi-disciplinary team of appropriate size,
specialization is simply not possible
• Task pairing and sharing grows everyone on the
team
• Team members focus shifts from fulfillment of
their own duties to the overall success of the
team
52. ARE YOU THE RIGHT SCRUM MASTER?
• Good Scrum Masters are fit via temperament
and facilitation skills NOT job title
• Good Scrum Masters are ferocious advocates
for their teams
53. WORKING WITH DEPENDENCIES
• Prioritization of the Product Backlog should be
used to synchronize dependencies
• When there are multiple scrum teams working
on 1 product, all teams must have a shared
definition of done
• Work should not be considered done until it is
integrated and tested
56. • Next Agile Leadership Series: The Definition of Done: August 1, 2013
• Professional Scrum Foundations Course: August 15-16 in Charlotte!
• A successful Agile implementation begins with comprehensive training Contact us
to register for our Scrum training today!
Contact Information
Jim Milam/ Nick Bourdon/ Matt Brookshire
210 East Trade Street
Suite C-440
Charlotte, NC 28202
(704) 936-4444
Cardinal Solutions Group
