Grow your career.

Level up for the future.

Intro to Agile and Scrum

Patrick van Abbema
2

Instructor Bio

• Patrick van Abbema, MBA, PMP, CBAP, CSP, CSM, ITIL

• Experienced Management Consultant with over 25 years of extensive experience.
• I focus on two project management specialty areas:
• Agile project management and
• Digital Transformation
• I have several progressive accomplishments as a senior management consultant in Information Management (IM),
Information Technology (IT), Defensive Cyberspace Operations (DCO), Customer Relationship Management (CRM),
Organizational Change Management (OCM), Enterprise Resource Planning (ERP), Enterprise Content Management (ECM)
and Bimodal IT solutions. I have managed organizational change management initiatives that involved the development of
coaching skills, process analysis, technology implementation, strategy development, and operational improvement services.

• Linkedin Profile: https://www.linkedin.com/in/pvanabbema/

Agenda
01. Day 1 - Section 1-5
02. Day 2 – Section 6-14
4

Exercise - Discussion
Thinking back to past projects, what were your biggest
challenges (ex., unrealistic schedules)?

Using post-it notes, take 5 minutes to write down 3

project challenges you have faced in the past.

NOTE – This is brainstorming technique called

brainwriting or method 6-3-5 (6 people - 3 ideas in 5
minutes)
Logistics

• Please mute your phones, and other noise making

devices

• Feel free to stand up and stretch when you are

feeling like you need to wake up or just move about

• Interactive – please ask questions

6

Section 1
Introduction –
Fundamentals of Agility
Section Learning Objectives
• The learning objectives for this section are:
– Understand the fundamentals of Agile Scrum
– Review the Agile Product Life Cycle
– Describe the Agile roles and responsibilities
– Contrast Scrum with Waterfall
8

What Is Agile?

• Agile is a framework that is used to structure, plan, and

control iterative and incremental development. When
applied to management, agile means that projects and
processes are managed dynamically and flexibly.
Lower planning and management intensity enable fast
implementation of a project, high adaptability, and
considerable autonomy.
• Agile Scrum is one of the many “flavours” of Agile, but it
is the most popular
The Agile Manifesto
Statement of Values

Individuals and
over Process and tools
interactions
Working software Comprehensive
over
(product) documentation
Customer
over Contract negotiation
collaboration
Responding to
over Following a plan
change

Source: www.agilemanifesto.org
The Agile Way

FAST - Sprints (time-boxes) make it easier to adapt to

changing market conditions.

PRIORITIZED - Each user story and task has a clear and

distinct success metric.

FOCUSED - Transparency and a “points” system make

prioritization a rational and productive conversation

PREDICTABLE - Daily “stand-up” plus the points system

help to identify blockers & eliminate surprises effectively.
11

Agile Principles
1. Satisfy the Customer
2. Welcome Change
3. Deliver Frequently
4. Work as a Team
5. Motivate People
6. Communicate Face-to-Face
7. Measure Working Software
8. Maintain Constant Pace
9. Excel at Quality
10. Keep it Simple
11. Evolve Designs
12. Reflect Regularly
Exercise 1A: Review the Scrum Terms and
Concepts Cheat Sheet
• As an individual, review the Scrum Cheat Sheet
1. Identify key terms and concepts
• As a class
2. Discuss which terms sound familiar, which may
be new, and which may have caused confusion
in your work environment
• As individuals or groups
3. Refer to the Cheat Sheet when new terms and
concepts are introduced, or when working on
exercises
High Level Agile Scrum Framework
Roles

•Product Owner
•ScrumMaster
•Team Ceremonies

•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Artifacts

•Product backlog
•Sprint backlog
•Burndown charts
Scrum Roles – High Level
• Scrum Master
• Coach/Lead the Scrum team
• Ensure team effectiveness
• Product Owner
• Prioritize the Product backlog
• Ensure project success
• Scrum Team
• Small (5-9), self-directed team
• Cross-functional (BA, Dev, QA, DBA, UI, etc.)
• Multiple Scrum Teams (Scrum of Scrums)
Agile Product Life Cycle (SCRUM)

NOTE :
We will discuss in detail
later in the course
 AGILE METHODOLOGY
Scrum Process
Information from end-users,
customers, team and Burndown /
stakeholders Up Charts
Daily stand-up
Meeting

every
PRODUCT OWNER the Team Scrum Master 24 H
Product Backlog Review
Refinement Developmen
Team agrees on
Features how much to Tasks t
& Tests
complete by
sprint's end
Sprint
1-4 Weeks
Daily
Scrum

End product
Sprint Sprint Review &
Retrospective
Planning Sprint
Planning
meeting
Product Sprint Sprint end date, goal and team
Backlog Backlog deliverables do not change Retrospective
Agile Scrum in Less Than 100 Words

•Agile 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 services and/or software (every
two weeks to one month).

•The business sets priorities. Teams self-

organize to determine the best way to deliver the
highest priority features.
17
Waterfall vs. Agile
Waterfall Agile
Plan Driven Change (Learning) Driven

Infrequent Team Communication Continuous Team Communication

Deliver Once in “Big Bang” Deliver in Short, Business-Focused

Fashion, Typically 9 – 12 Months Phases, Typically 2 – 3 Months
Develop in Layers: Presentation, Develop in End-to-End Functional Slices
Persistence, Business, etc.
Integration of Different Layers Continuously Integrate Code
Occurs at End of Build Phase Throughout (Daily Builds)
Testing as Separate Phase at End of Fully-Automated, Continuous Testing at
Project, Emphasizing Functional Level Both Functional and Unit Level

High Cost of Change Low Cost of Change

Expects, accommodates Changes

Attempts to Nail Down Requirements
to Requirements
18
19

Exercise 1B: Challenges to Building End-to-End

Systems
Brainwrite the following answers:
1) How would you see Agile helping teams build end-to-end
systems?
2) What are some of the challenges you think you will face?

Brainwriting – Write 3 ideas in 5 minutes and then

discuss as a group
20

Introducing Agile Scrum

to the Organization
• It is about moving ideas between minds (attitude, trust,
distance, tacit knowledge, work environments)

• It is about identifying the Shifting of Power, new roles

(decision makings, role definitions, power centers)

• It is about knowing the Implications of distance, face-to-face,

tacit versus documented, culture

• Increasing team cohesion, visibility displays, collaborative

requirements/planning applications
Section Summary and Conclusions
The learning objectives for this section were:
– Fundamentals of Agile Scrum
✓ Simulation exercise
✓ Manifesto (Statement of Values)
✓ 12 Principles
– Review the Agile Product Life Cycle
– Describe the Agile roles and responsibilities
– Contrast Scrum with Waterfall

21
22

Section 2
Value Driven Delivery –
Identify Case Study
and Agile Team
Section Learning Objectives

• The learning objectives for this section are:

– Understand why agile development focuses so
heavily on value and adaptive planning
– Review the Agile application lifecycle, Agile
project characteristics, and Agile roles
– Select a Case Study and
assemble the Agile Team

23
24

Value-Driven Development

• Agile is based on iterative and incremental

development, where requirements and solutions evolve
through collaboration between self-organizing, cross-
functional teams.

• Unlike traditional 6-12 month planning and execution

cycles, Agile allows the team to adapt to fast-changing
conditions, respond to immediate needs, and prove ROI
quickly and consistently.
Agile Scrum Characteristics
• Self-organizing teams
• Product progresses in a series of 2 to 4 week
long “sprints”
• Requirements are captured as items in a list of
“product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile
environment for delivering projects

25
Exercise 2a: Select the Case Study
Select an initiative for your Agile case study
• In groups that will become an Agile team
1. Identify projects from your work that meet these criteria:
• Not too far along, or not started (< 20% complete)
• Not too small or too big (6-18 months) -- A single phase of a
larger product can work
• Sufficiently complex to be interesting
• A team member knows (or can improvise) enough to play the
role of Product Owner
2. Select the best candidate for an Agile project
• In teams with the Instructor
3. Discuss alternatives, focusing on merits for subsequent
exercises
26
Assemble the Agile Team
Roles

•Product Owner
•ScrumMaster
•Team Ceremonies

•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Artifacts

•Product backlog
•Sprint backlog
•Burndown charts
27
AGILE METHODOLOGY
Scrum Role Allocation
PRODUCT SCRUM
OWNER MASTER
The Product Owner is The Scrum Master acts
responsible for economic as the moderator of the
success, and represents project team, and
the interests of users and ensures compliance
stakeholders SCRUM with the rules

CUSTOMERS TEAM MEMBERS

The customer pays They are self-organized
for product and responsible for
development in development tasks
order to use the
product later ROLES
STAKEHOLDER
S
Stakeholders
communicate their
general product
needs and
requirements
SCRUM – TEAM
Supporting Activities
▪ Coaching in self-organization and teamwork and removing impediments
from the development team
▪ Helps the development team to create high-value products
▪ Facilitates Scrum implementation

PRODUCT OWNER DEVELOPMENT SCRUM MASTER ORGANIZATION

TEAM

▪ Finding techniques for effective Product Backlog ▪ Leading and coaching the organization in its
management Scrum adaption, planning Scrum implementation
▪ Helping the Scrum team understand the need for clear within the organization
and concise Product Backlog items ▪ Helping employees and stakeholders understand
▪ Facilitates Scrum implementation and enact Scrum and empirical product
development

Source: ©Scrum.Org and ScrumInc., Ken Schwaber and Jeff Sutherland: Scrum Guide
Product Owner

• Define the features of the product

• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
and Return on Value (ROV)
• Prioritize features according to market value
• Adjust features and priorities between (not during)
every iteration, as needed
• Accept or reject work results

30
Identify the Product Owner

Product decision-maker
• Authority to make decisions
• Responsibility for product success
• “Single Wring-able Neck”
• One Individual
• May represent others
• Speaks for all product users
• Knows business processes
• Understands difficulties and unique needs
31
Exercise 2b: Select the Product Owner
• In small groups
1. Discuss the Case Study stakeholders
2. List the people or groups the Product Owner
must represent
3. Identify who the ‘real-life’ Product Owner should
be, and why (and who will assume the Product
Owner’s persona for the Case Study)
• As a class
4. Each group presents its Product Owner and
decision criteria

32
Build the Scrum Team

Establish the team early so they can:

• Participate in project initiation
• Help with the Product Backlog
• Produce initial (coarse-grain) estimates
• Jell as a team before the work begins

33
The Scrum Master

• Represents management of the project

• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences

34
Team Collaboration

• Ideal team members

• Identify with the team's goals
• Empowered and entrusted with tasks
• Supported by manager
• Experienced and knowledgeable in field
• Represent colleagues
• Time to participate
• Want to contribute to the success
• Avoid representation through proxy

35
Exercise 2c: Build the Scrum Team
• In small groups
1. Discuss competencies needed
2. Identify who the ‘real-life’ Scrum Master should
be, and why (and who will assume the Scrum
Master’s persona for the Case Study)
3. Identify all of the Committed Team roles (full-
time and part-time) and who will play them, and
who else is on the Non-Committed Team
• As a class
4. Each group presents its Team composition

36
Section Summary and Conclusions
The learning objectives for this section were:
– Value and adaptive planning
– Agile application lifecycle, Agile project
characteristics, and Agile roles
– Selecting a Case Study, assembling the Team
✓ Product Owner
✓ Scrum Master
✓ Committed Team
✓ Non-Committed Team

37
38

Section 3
Team Member Engagement
Envision the Product
Section Learning Objectives

• The learning objectives for this section are:

– Understand the motivation behind team member
expectations
– Develop high-level functionality to support goals
and strategies
– Develop an overview for realizing
the Vision with Agile ceremonies

39
40

Exercise 3a: Review Agile Checklist

• In small groups
1. Review the Agile Checklist document
• Agile Development Rhythms
• Meeting Checklists – Strategy Meeting
• Getting Started
2. Discuss and capture the key elements that are in the
checklist
SCRUM – Preparation
N
, 3…
1,2 Sp
t

rin
SPRINT

rin

tC
PLANNING

Sp
MEETING DAILY SCRUM /

ycl
PREPARATION DAILY WORK

e
▪ Business case & funding UPDATE RELEASE N
▪ Contractual agreement PRODUCT
▪
▪
Vision
BACKLOG
SCRUM
PROCESS
Initial Product Backlog
▪ Initial Release plan PRODUCT
INCREMENT
▪ Stakeholder buy-in
▪ Assemble team SCRUM
MASTER
PRODUCT PRODUCT
BACKLOG SPRINT OWNER
RETROSPECTIVE
IMPEDIMENT PRODUCT BACKLOG
LIST SPRINT
BURNDOWN REVIEW

PRODUCT USERS
BACKLOG SPRINT
DELTA BACKLOG
REPORT SPRINT
TEAM
BACKLOG MEMBERS
BURNDOWN STAKEHOLDER
42

Team Member Needs

• Identify and engage effective and empowered business

team members who are engaged with the team
• Identify and engage all stakeholders (current and future)
by promoting knowledge sharing early and throughout
the project to ensure the unimpeded flow of value
throughout the lifespan of the project

Source: PMI ACP certification summary

43

Product Envisioning –
an Agile Best Practice
• A common agile practice is to perform some high-level
requirements envisioning early in the project to help come to a
common understanding as to the scope of what you're trying to
accomplish.
• The goals at this point are to identify the business goals for the
effort, develop a common vision, and swiftly identify the initial
requirements for the system at a high-level.
44

Product Vision and Scope

Project Scope in Agile
environment is dynamic
• Start with high-level business
and technical needs
• Envision ‘Epics’ to be broken
down into features, stories,
development activities
• May need more envisioning to
refine product and service
groupings, business process
capabilities, and value streams
Articulate Business Functionality

High-level features; not all of the detail

• Either User Stories
• As a {business role},
• I need {specific functionality},
• So that {business purpose}.
• Or high-level Use Case outline
• User goal and ‘happy path’ outcome
• Measures of success: “Given, when, then …”

45
Articulate Technical Functionality

High-level; not all of the detail

• Either technical capabilities
• Infrastructure
• Operational expectations
• Architecture framework
• Or high-level User Story
• As a {system component},
• I need {specific functionality},
• So that {business purpose}

46
Articulate Technical Functionality

High-level; not all of the detail

• Either technical capabilities
• Infrastructure
• Operational expectations
• Architecture framework
• Or high-level User Story
• As a {system component},
• I need {specific functionality},
• So that {business purpose}

47
Agile Realization
Business motivation – a set of product, service or
architectural needs (Product Vision) – realized in:
• Product Backlog consists of high-level stories (Project
Vision, Epics and Features)
• Minimum marketable feature set (Release Plan)
• New initiative (Sprint Zero, Spikes)
• Rate of development (Velocity, Burn Down)
• Sprint Backlog (Stories, Tasks, Test Criteria)
• Complex projects (Sprint Stabilization)
• Multiple initiatives (Scrum of Scrums)

48
Section Summary and Conclusions
The learning objectives for this section were:
– Understand the motivation behind stakeholder
expectations
✓ Stakeholder engagement
✓ Strategy meeting
✓ Elevator pitch
– Develop an overview for realizing
the Vision with Agile ceremonies
✓ Agile checklist

49
50

Section 4
Initiate an Agile Project–
Planning Releases
Section Learning Objectives
• The learning objectives for this section are:
– Discuss how you would initiate an Agile project
– Discuss common practices that work when
planning Agile projects
– Determine how you will organize features and
releases

51
52

Exercise 4a: Adapting to a

Change-Driven Project Plan
• Group discussion
1. How do you adapt to a change-driven approach from
a (traditional) plan-driven approach?
Questions to ask:
- Do you have all the facts that will provide clarity for planning the
ENTIRE project?
- Are there any known unknowns?
- Do you have multiple options to choose from during the project?
53

Planning in the Agile

Product Development Life Cycle

“Five Levels of Agile Planning”

54

Initial Release Plan

The initial release plan is understood to be rough. It must be

detailed enough only to get us started by predicting that the
project will deliver enough return on investment to more than pay
for it.

REMEMBER
In Agile projects we plan continuously, and we correct our course
as we go.
55

Product-Level Planning
Customer-specific product release success
criteria share the following characteristics:
• Identify specify current or prospective customer
‘personas’ so the team knows who they are
trying to satisfy
• Define specific actions by the customer that will
indicate the product release has met its goal
• Set timeframes during which actions must take
place for the product release to be considered a
success
56

Prioritize Releases
Since initial Product Backlog items can be difficult
to prioritize, it’s useful to prioritize Releases first,
then items within and, if necessary, across themes

Factors to consider when determining priorities:

• Value
• Knowledge
• Uncertainty and risk
• “Releasability”
• Dependencies
57

Group Initial Product Backlog Items

58

Exercise 4b: Create Release Plan

Using the case study and Release Planning checklist discuss an

initial Release Plan
• In teams
1. Expand business and technical functionality (more features
and capabilities) to produce an initial Product Backlog
2. Team and Product Owner consider multiple factors to
organize features in a Release Plan
• As a class
3. Discuss release schedule and constraints
Section Summary and Conclusions
The learning objectives for this section were:
– Discuss how you would initiate an Agile project
✓ Five Levels of Agile Planning
– Discuss common practices that work when
planning Agile projects
✓ Release Plan Meeting

59
60

Section 5
Coarse-Grain Estimates
and Time-Boxed Iterations
Section Learning Objectives
• The learning objectives for this section
are:
– Determine high-level items in Product
Backlog
– Estimate at the level of detail sufficient for
planning and prioritizing
– Estimate throughput (delivered items) within
time and resource constraints

61
62

Embrace High-Level Vision

and Release Plan
Product Life Cycle budget requires estimating how
many Sprints will it take to achieve the desired
outcome. Individual Sprint components may
include:
• Modeling
• Implementation and testing
• Deployment, configuration management, training
and documentation
• Synchronization, refactoring and data hygiene
• Environment changes
Develop the Product Backlog
• A list of all desired work on
the project
• Each item has value to the
users or customers of the
product
• Prioritized by product owner
(and the team)
• Become ‘requirements’
• Allows team to estimate items
when needed, at the level of
This is the Product detail needed
Backlog
63
64

Guidelines for the Product Backlog

Guidelines for creating the Product Backlog are:

• Keep your Product Backlog between 50 and 100 items total
• The top 20 to 40 items are small enough to be estimated at a
high level
• Put acceptance criteria on top 20-40 items
65

Establish Decision and Acceptance Criteria for

User Stories
Writing user stories is simple if you follow these simple steps:

1. As a [role], I can [feature] so that [reason]

2. Use index cards and a Sharpie
3. Make it testable with acceptance stories
• Given [context], when [event], then [outcome]
4. Connect the dots [start the conversation]
Exercise 5a: Elaborate Business
Functionality
• In small groups
1. Agree on documenting with User Stories
2. Decompose high-priority business
functionality into at least 10 user stories (one
per 3x5 sticky note) with success criteria
3. Note technical functionality associated with
user stories as additional success criteria
• As a class
4. Each group presents stories they have added
to their Product Backlog

66
67

Estimate Complexity Using

Story Points
• Relative measure of effort to implement User Stories
• Abstract number for ‘how hard’ the story is
• ‘Hard’ could be related to technical functions, complexity,
unknowns and deployment tasks
• Defined by team and constant over all Sprints
• Examples (shirt size, scale 1-10, or fibonacci):
• “Send to a Friend” = 2
• “Shopping Cart” =8
Coarse-Grain Estimates

• Team estimates relative complexity

• For each Business User Story (or Use Case)
• “Coarse-grain” estimate based on high-level functionality and
technical factors
• Unit of measure: “Story Points”
1 point = routine story, low effort, little or no complexity, with
an average team doing concentrated, un-interrupted work
• Scrum Master facilitates estimation

68
Exercise 5b: Estimate Complexity
(Coarse-Grain)
• In small groups
1. Estimate each story
• ScrumMaster facilitates the game
• Team does the estimating
• Product Owner does not estimate!
• Estimate Story Points
2. Write the effort estimates on the story cards
• As a class
3. Each group presents their Estimates

69
70

Agile (Scrum) Is Time-Boxed

• Invert the Iron Triangle

• Fix date and resources
• Vary scope
• Reduce waste
• Estimate throughput

• Optimize value (each Sprint; entire Project)

• Prioritize needs
• Deliver maximum value in time allowed
Project Time-Box Considerations

• Required end-date
• Project budget
• Resource availability
• Others?

The project will deliver the greatest possible business value (as
defined by the Product Owner) within the project time-box

71
72

Establish Core Hours

• How will the team work during the day?

• How many hours can you get from your committed resources
during the sprint?
• What impact does this have the team’s capacity?
Team Velocity

• Over a number of sprints you will see how many story points you
can achieve – the velocity

• This allows you to predict throughput based on number of story

points in the backlog

REMEMBER – one team’s story point is not the same as another's

73
Project Time-Box

• Time-boxing represents the project timeline,

given Product Backlog and Team Velocity
• Begin date
• End date
• Sprint length
• Number of Sprints

Jan Feb Mar Apr May Jun Jul

Sprint #1 Sprint #2 Sprint #3 Sprint #4 Sprint #5 Sprint #6 Sprint #7
74
Section Summary and Conclusions
The learning objectives for this section were:
– Determine high-level items in Product Backlog
✓ User stories and acceptance criteria
– Estimate at the level of detail sufficient for
planning and prioritizing
– Estimate throughput (delivered items) within
time and resource constraints
✓ Velocity
✓ Time-box

75
76

Section 6
Plan the Iteration (Part I)
Section Learning Objectives
• The learning objectives for this section are:
– How to plan an Agile iteration (Sprint)
– Review Day 1 planning activities, roles and
expectations
– Address common challenges of Agile planning

77
Sprint Planning

• Scrum projects make progress in a series of

“Sprints”
• Typical duration is less than a calendar month
• Time-boxing leads to better rhythm, efficiency
• Potentially shippable product is specified,
designed, coded, tested and accepted
• Sprint Planning selects Sprint Backlog items
and develops understanding of Tasks

78
79

Iteration Planning in Context of Agile Unified

Process
• ‘Inception’, ‘transition’ and ‘production’ phases
apply to the flow within a Sprint, and to the
overall plan across multiple
Sprints
80

Exercise 6a: Sprint ‘Zero’ Activities

• In small groups, discuss

1. What is Sprint Zero?
2. What activities could be included in Sprint Zero? For a
simple project? For a complex project?
• As a class
3. Do you expect the first sprints to be clean and well
executed? Why or why not? How do you address this?
81

Spikes

• Stories to
• Research technical and functional issues
• Secure budget and reach financial decisions
• Prototype capabilities that require feedback
• Help understand complexity
• Often ‘thrown away’
• Output is a better estimate for original story

If we knew what we were doing it wouldn’t be research - Albert

Einstein
82

Master Test Plan

An Agile master test plan includes:

• Intro with objectives and team members
• Scope (what will be tested)
• Assumptions and risks
• Test approach (including automation)
• Test environment
• Milestones/deliverables with the schedule
83

Backlog Accuracy

Continuous planning is much more accurate if it occurs on at least

two levels:
• At the release level, identify and prioritize the features the PO
must have, would like to have, and can do without by the
deadline
• At the iteration level, pick and plan for the next batch of
features to implement, in priority order
Features too large to be estimated or delivered within a single
iteration must be broken down or researched further
1st Half of Sprint Planning Meeting

• First part of the meeting - collaborative effort

• Product Owner, Team, Scrum Master
• Anyone who wants to attend is welcome
• Set Sprint goal and scope
• Based on progress to date and any changes
• Learn more detail about highest priority items
• Accept Product Backlog items into Sprint
• Time-boxed marching plans for the Team

84
Sprint Goal and Scope

• Small reversible steps

• Welcome change
• Cross-functional team
• Include design and testing
• Maintain constant pace
• Share commitment
• ‘DONE’
This Sprint • Get feedback quickly

85
Identify PBIs for the Sprint
ScrumMaster facilitates while Product Owner and
Team collaborate to:
• Break down larger stories
• Prioritize stories
• Decide which PBIs may be put into production
• Team collaborates to:
• Review velocity and capacity
• Select stories for current iteration

86
Story Size and Sprint Capacity
If XYZ story can be accepted in one Sprint:
• Add support for XYZ
• Consider adding another story

If XYZ story cannot be accepted in one Sprint:

• Consider what elements can be worked
• Create User Interface/Workflow for XYZ
• Process normal XYZ success (no exceptions)
• Apply all business rules to XYZ

87
Exercise 6B: Confirm and Refine High-Priority
Product Backlog Items
• Using the Iteration Planning checklist
1. Using the Backlog PBI Create
1. An EPIC
2. Five Features
3. Three Stories for the first feature
4. Estimate complexity of the User Stories (T-
Shirt sizes, or 1.3.5)
• As a class
3. Discuss the advantages and disadvantages of
this approach
88
Section Summary and Conclusions
The learning objectives for this section were:
– How to plan an Agile iteration (Sprint)
– Review Day 1 planning activities, roles and
expectations
✓ Iteration Plan Meeting
✓ Estimating with T-Shirt Size or 1,3,5
– Address common challenges of Agile planning
✓ Sprint ‘0’, Spike, Master Test Plan

89
90

Section 7
Plan the Iteration (Part II)
Section Learning Objectives
• The learning objectives for this section are:
– How to complete planning for a Sprint
– How to estimate at the task level and identify
risk factors
– Understand who commits to and approves the
Sprint plan

AIM
91
92

2nd Half of Sprint Planning Meeting

Second half of meeting - collaborative effort within Team:

• Clarify Sprint Backlog items
• Break down stories to associated tasks
• Identify modeling requirements
• Create initial list of issues, dependencies, assumptions, non-
functional requirements
• Estimate tasks (Ideal Days or Hours)
• Definition of DONE
• Tasks become committed for the Sprint
Estimate Relative Effort (Fine Grain)

• Team estimates relative effort

• For each task
• ‘Fine-grain’ estimate based on team’s experience and
different perspectives
• Scrum Master facilitates estimation
• Option:
• Self-select tasks first, then team member estimates
own tasks

93
Sprint Backlog Example

Includes rough
estimates

Prioritized by
value & risk

Better to describe Publicly

as user stories visible
94
Finalize the Sprint Plan

Scrum Master Facilitates:

• Product Owner and Team collaborate to finalize what will be
delivered in the Sprint, based on:
• Sprint Goal
• Initial plan for this Sprint
• Team’s velocity
• Other information

95
Section Summary and Conclusions
The learning objectives for this section were:
– How to complete planning for a Sprint
– How to estimate at the task level and identify
risk factors
✓ Ideal Days
– Understand who commits to, and approves, the
Sprint plan

96
97

Section 8
Tools and Techniques for Managing
Scrums
Section Learning Objectives
• The learning objectives for this section
are:
– Review the four main tools and techniques
that guide progress
– Discuss how to use these techniques in an
Agile environment

98
99

Manage the Scrum

To maintain rhythm and sustainable pace of work,
manage Scrum activities through
• Self-selecting tasks near to priority order
• Displaying work in progress
• Communicating status and spotting obstacles
daily
• Reporting progress that is visible, highly
transparent, and easily understood
Daily Scrum Meeting
• Only 15 minutes a day
• Stand up meeting
• Only “committed”
members can talk
• 3 questions are asked
• Commitment and
accountability
• Say what you do, do what
you say
This is the Daily
• Whole world is invited
Scrum Meeting
100
101

Example #2 SCRUM Task Board

102

Burndown Chart
• On a Scrum project, the team tracks its progress
against a sprint or release plan by updating a
burndown chart

• The horizontal axis of the chart shows the time, and

the vertical axis shows the amount of work remaining

• Work remaining can be shown in whatever unit the

team prefers – story points, ideal days, team days,
and so on
SCRUM – BURNDOWN CHART
104

Exercise 8a – Discussion –Create a Scrum

board with work streams
• As a team, discuss how you would create a
Scrum board with work streams
Section Summary and Conclusions
The learning objectives for this section were:
– Review the four main tools and techniques
that guide progress
✓ Self-managing teams
✓ Daily Standup meeting
✓ Task Board
✓ Burndown Chart
– Discuss how to use these techniques in an
Agile environment

105
106

Section 9
Running the Sprint
Section Learning Objectives
• The learning objectives for this section are:
– Understand how requirements emerge, change
and are satisfied during the Sprint
– Discuss the importance of self-managed teams
– Demonstrate how the Daily Standup Meeting
fosters collaboration and communicates status
to committed and non-committed resources

AIM
107
Paradigm Shift in Requirements

• Plan-driven limitations
• Documents do not generate value directly
• Unidirectional from author perspective
• Agile ‘User Story’ represents a conversation
• Visual display, easily annotated
• Whiteboard modeling for clarity and insight
• ‘Given, when, then’ conditions
• Automated tests confirm details
• Artifacts (cards) are only temporary

108
109

Select ‘Next Priority’ Task

• Each team member selects (one) task-level item

• Next highest in priority ranking
• Dependency item, cover item or other association with related
requirements
• Skill level and capacity
• Unresolved issues
• Level of collaboration
• Re-estimate in hours or ideal days
• Post on Task Board
110

Validate Agile Requirements

• Identify assumptions
• Define measurable evaluation criteria
• Determine business value
• Determine dependencies for benefits realization
• Evaluate alignment with business case and opportunity cost
111

Create Test Scenarios and Test Cases from User

Stories
• User story detail (exhaustive, comprehensive)
• Measures of success
• Non-functional quality of service criteria
• Integration and synchronization
• Automated testing

Note – Demonstrate completed work items at the Sprint Review

meeting (Sprint Demo)
112

Managing Scrums with

Daily Stand-Up
Committed Team with cross-functional skills does the actual work

3 Questions are asked:

• What have you completed since we last met?
• What are you planning to complete until we meet again?
• What, if any, impediments are you encountering that are
preventing you from completing your work?
Daily Scrum Rules
• Purpose
• Status update to synchronize Team’s work
• Highlight ‘WIP’ ‘done’ or new impediments
• Foster collaboration and self-organization
• Logistics
• Every business day, usually early in the
morning
• Short (time-boxed) and stand-up (no chairs)
• Report status and take discussion off-line
• NO presentations, problem-solving or
decision-making!

113
114

Review:
Committed vs. Non-Committed
• Committed resources have skin in the game
• Everyone doing technical work on the project
• Competencies (development, testing, DBA …)
• So they may speak and show accountability
• Non-Committed resources only contribute
• Everyone else
• Executive, Sponsor, Manager, Customer …
• So they must remain silent, but remain
engaged by listening and observing
progress
Removing Impediments to Progress

Scrum Master ensures:

• Interested Team members collaborate after the meeting to solve
Technical problems
• SM action items to clear the Team’s path and secure other
groups’ cooperation to remove Organizational roadblocks
• SM action items to shield team from Political infighting
• SM action items to defend process integrity against attempts to
circumvent Scrum practices

115
Authority to Change Sprint Backlog

Only the Team can change the Sprint Backlog in the middle of a
Sprint
• Add items if necessary to achieve the Sprint goal or if resources
are available for more work
• Remove/modify items if the Sprint goal is still achieved AND if
the Product Owner agrees
• Priority was ‘low’ during planning
• Scope has changed
• Assess changes in Sprint Review and add back to the Product
Backlog for next Sprint
116
Section Summary and Conclusions
The learning objectives for this section were:
– Understand how requirements emerge, change
and are satisfied during the Sprint
✓ Facilitated workshops, preshops
– Discuss the importance of self-managed teams
– Demonstrate how the Daily Standup Meeting
fosters collaboration and communicates status
to committed and non-committed resources
✓ Roles and authority to change

117
118

Section 10
Sprint Review
Section Learning Objectives
• The learning objectives for this section are:
– Understand why and how to conduct a Sprint
Review

119
Traditional Acceptance and Sign-off
• Customer acceptance is important for
requirements approval

• Team acceptance is important because they

agree to accept the requirements and build
them into a product

• Sign-off on a requirements document is an

act of customer approval of the requirements
and brings closure before the requirements
development process
120
121

Exercise 10a: Discuss Review Planning

Checklist
• In small groups
1. Review the Iteration Review meeting checklist
2. Discuss and capture the key elements that are in the
checklist
• As a class
3. What makes Agile (Scrum) Sprint Review different from a
traditional project approach?
Sprint Review: Working Product
Is Showing Progress
Sprint Review focuses on the finished product increment
• Did the team produce what they promised?
• Does it meet the Product Owner’s expectations?
• Is it acceptable to the customers?
• Was the Sprint goal achieved?

122
123

Prepare for Sprint Review

• Team presents what it accomplished

• Typically takes the form of a brief demo of new features or
underlying architecture
• JAD workshops, prototypes, testing occur within the Sprint
as a completed Task
• Informal
• 2-hour prep time, no slides
• Whole team participates (invite the world)
• Product Owner accepts deliverables, adjusts Product Backlog
124

Organizational Readiness

What is it?
• Organizational readiness reflects ability to accept and implement
change
• Requires necessary knowledge, skills, resources to assess
and support
• Critical to successfully implementing complex service delivery
changes
• Time to plan is early, while time to affirm is now
• Accountability may rest with the Product Owner
125

Definition of Done (DoD)

Definition of Done (DoD)

• The exit-criteria to determine whether a product backlog item is
complete. In many cases the DoD requires that all regression
tests should be successful.
126

Input for the Next Sprint

• Update the user stories and their priorities as
customers' needs change
• Break down user stories that are likely to be
implemented in the next sprint
127

Exercise 10b: Conduct a Sprint Review

• In small groups using the Review meeting checklist

1. Prepare for a Sprint Review
• Assume goal is complete but certain tasks were changed
• Consider this Sprint in context of Release Plan
2. Conduct the Sprint Review
• As a class
3. Contrast Review meeting with traditional UAT
Section Summary and Conclusions
The learning objectives for this section were:
– Understand why and how to conduct a Sprint
Review
✓ Sprint Review meeting
✓ Validation
✓ Organizational Readiness
✓ Definition of Done (DoD)

128
129

Section 11
Sprint Retrospective
Sprint Retrospective

Quick Lessons Learned at end of every Sprint

• What is working well for the team?
• What is problematic for the team?
• What practice changes shall we try?
• Not more than 2 or 3
• Low-hanging fruit
• Determine at the next Retrospective
if the changes will be made permanent

130
Key Process Indicators

• Agile processes should be tailored to better serve the

organization and project
• Success metrics (quality indicators) for Agile
• Planning (velocity as a reliable tool)
• Collaboration (quality of relationships)
• Requirements (validity after testing)
• Deliverables (working software)
• Deployment (service management)
• Assessment mechanism: open discussion

131
Sprint Retrospective Guidelines
• Done after every Sprint
• Typically 15–30 minutes
• ScrumMaster facilitates open discussion
among committed team
• Review improvements from previous Sprint
• Add any impediments not cited in Daily
Scrum
• Include non-committed team for part of the
discussion as appropriate
• Identify most important issues to work on for
next Sprint, focusing on process not people
132
133

Exercise 11b: Pop Quiz!

• Is it OK for a project to have more than 1 Product Owner? Why?

• What is the Product Owner’s primary responsibility?
ScrumMaster? Team Member?
• Define these terms:
• Time-boxed
• Self-organizing team
• Planning poker
• Definition of Done
Section Summary and Conclusions
The learning objectives for this section were:
– Understand why and how to conduct a Sprint
Retrospective
✓ Retrospective meeting
✓ Metrics

134
135

Section 12
Boosting Team Performance
Section Learning Objectives
• The learning objectives for this section are:
– Raise concerns with introducing Agile methods
in a Waterfall culture
– Discuss scaling larger projects and portfolios
– Introduce performance issues facing Agile
teams

AIM
136
Scaling with Larger Teams
Can committed resources represent small
groups of technical peers?
• Factors in scaling
• Type of application
• Team size
• Team dispersion
http://whitewaterprojects.com/20
• Project duration 10/09/17/why-is-7-2-the-ideal-
scrum-team-size/#

137
The Dangers of Agile Scrum
• It’s hard!
• It requires significant change
• It makes all dysfunction visible
• It demands honesty, transparency and
accountability
• Bad products will be delivered sooner, and
doomed projects will fail faster
• Partial adoption may be worse than none at all
• Be forewarned: many Scrum adoptions fail

138
139

Begin with Stakeholder Engagement

Keys to improving stakeholder engagement:

• Team Formation
• Team Empowerment
• Team Collaboration
• Team Commitment

Then, as an on-going activity:

• Coach
• Solve Problems
140

Exercise 12a: Discussion on issues with people

and process
Based on the organization’s current competencies and future
needs, how can it best manage the transition to Agile?
1. What are the process issues
2. What are the people issues
3. How can we remove the impediments to progress?
Section Summary and Conclusions
The learning objectives for this section were:
– Raise concerns with introducing Agile methods
in a Waterfall culture
– Discuss scaling larger projects and portfolios
– Introduce performance issues facing Agile
teams

141
142

Section 13
Transitioning from Waterfall
Waterfall Cultural Roots

• Origins in structured programming with quality

process control Requirements

• Project management Planning

• Known requirements
• Variance from plan Design

• Management culture, project Build

leadership, project focus
• Business analysis Test

• Plan-driven requirements management Deploy

143
Waterfall vs. Agile
Waterfall Agile
Plan Driven Change (Learning) Driven

Infrequent Team Communication Continuous Team Communication

Deliver Once in “Big Bang” Deliver in Short, Business-Focused

Fashion, Typically 9 – 12 Months Phases, Typically 2 – 3 Months
Develop in Layers: Presentation, Develop in End-to-End Functional Slices
Persistence, Business, etc.
Integration of Different Layers Continuously Integrate Code
Occurs at End of Build Phase Throughout (Daily Builds)
Testing as Separate Phase at End of Fully-Automated, Continuous Testing at
Project, Emphasizing Functional Level Both Functional and Unit Level

High Cost of Change Low Cost of Change

Expects, accommodates Changes

Attempts to Nail Down Requirements
to Requirements
144
145

Exercise 13a: Comparing Waterfall (Plan-Driven)

versus Agile (Change-Driven
As a class determine the advantages and disadvantages of the
Waterfall and Agile Framework
146

Module 14
Wrap Up and
Additional Information
Course Learning Objectives Summary

The learning objectives for this course were:

This course shall help you develop and enhance your

Agile skills so that they can provide significant value
to projects and the business enterprise

147
Agile Product Life Cycle (SCRUM)

NOTE :
✓ Discussed in detail!

148
Agile Reading List
• Agile and Iterative Development: A Manager’s Guide by Craig
Larman
• Agile Estimating and Planning by Mike Cohn
• Agile Project Management with Scrum by Ken Schwaber
• Agile Retrospectives by Esther Derby and Diana Larsen
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Software Development with Scrum by Ken Schwaber and
Mike Beedle
• Scrum and The Enterprise by Ken Schwaber
• User Stories Applied for Agile Software Development by Mike Cohn
• Lots of weekly articles at www.scrumalliance.org

149
150

Questions?