PMI-Agile Certified Practitioner

PMI-ACP Prep Workshop

LeadingAgile Atlanta
2180 Satellite Blvd Suite 400
Duluth, Georgia 30097
(678) 935 -4664
Rick Austin– Enterprise Agile Coach

Expert in Financial
Services Industry
PMI-ACP: Support Team Lead
Georgia State Grad PMI Agile Community of Practice: Volunteer

Agile Project Management

Volunteer and Leader

About me… Solutions

experience applying agile to Director of Development
small teams Agile Transition
large distributed teams Director, Program
change management Manager

Information Technology Applications Development

Director Manager
 Introductions
Let’s introduce ourselves, find out
why we’re all at this session

• What is your name?

• Why are you here?
• What is your level of expertise with
Agile?

3
 Learning Backlog

Write your questions on

Sticky notes as they Backlog

occur to you & affix

them to our Learning
Backlog.

4
 Approach
Participation is a Key to Success
• We will move quickly, but spend
appropriate time on material you find
especially useful
• I should be asking a lot of questions
• The key to success for our session is
participation
o Share your ideas and learning
o Tell me when to move on
o Tell me when to go into more detail

5
 Course Agenda
Exam Content Overview Risk The Scrum Process
What is the PMI-ACP Burndowns Initial Planning
Domains and Tasks Product Backlog
Qualitative vs. Quantitative Release Planning
Content Distribution Implicit vs. Explicit Sprint Planning
Tools & Techniques
Sprint Backlog
Knowledge & Skills Sprint
Community Guide of the PMI-ACP Scrum Sprint Review
Basic Understanding Daily Scrum
Scrum Process Overview Sprint Retrospective
Agile History
Leaders over time Planning
Waterfall Requirements Simulations and Exercises
Agile Manifesto Estimation Command-and-Control Exercise
Self-Organization Exercise
Why Agile? Roles & Responsibilities Batch and Flow Exercise
Product Owner Team Collaboration Exercise
Understanding the basics Theory of Constraints Exercise
ScrumMaster
The Team
Agile Methods User Story Writing
Lean Planning Poker
Affinity Estimating
Kanban Iteration 0/Release Planning
Extreme Programming Sprint Planning
Scrum Daily Standup
Review and Demo
Retrospective

6
What is the PMI-ACP?
 What the PMI-ACP and Agile are Not
PMI-ACP is not:
• A replacement for the PMP®
• PMI’s own flavor of Agile
• Without support from the Agile community

≠
• Going to make you an Agile expert
Agile is not:
• Something New
• A silver bullet
• An excuse for little or no planning
• An excuse for little or no documentation
• An excuse for poor quality
• Undisciplined
• Unproven

8
 PMI-ACP and Adoption Curve
The
chasm

ACP PMP

We are here! Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve

9
 Knowledge & Skills (50% of exam)
Percentage of Knowledge and Skill Content / % of Exam
Level 1 (66% / 33%) Level 2 (24% / 12%) Level 3 (10% / 5%)
(18 knowledge/skills) (12 knowledge/skills) (13 knowledge/skills)
Active listening Agile frameworks and terminology Agile contracting methods
Agile Manifesto values & principles Building high-performance teams Agile project accounting principles
Assessing and incorporating community and Business case development Applying new Agile practices
stakeholder values
Brainstorming techniques Colocation (geographic proximity)/distributed Compliance (organization)
teams
Building empowered teams Continuous improvement processes Control limits for Agile projects
Coaching and mentoring within teams Elements of a project charter for an Agile project Failure modes and alternatives
Communications management Facilitation methods Globalization, culture, and team diversity
Feedback techniques for product (e.g., Participatory decision models (e.g., input based, Innovation games
prototyping, simulation, demonstrations, shared collaboration, command)
evaluations)
Incremental delivery PMI's Code of Ethics and Professional Conduct Principles of systems thinking (e.g., complex
adaptive, chaos)
Knowledge sharing Process analysis techniques Regulatory compliance
Leadership tools and techniques Self assessment Variance and trend analysis
Prioritization Value-base analysis Variations in Agile methods and approaches
Problem-solving strategies, tools, and techniques Vendor management
Project and quality standards for Agile projects
Stakeholder management
Team motivation
Time, budget, and cost estimation
Value-based decomposition and prioritization

10
 Tools & Techniques (50% of exam)
Communications Planning, monitoring, and Agile estimation
• information radiator, team space, adapting • relative sizing/story points, wide band
agile tooling, osmotic • retrospectives, task/Kanban boards, Delphi/planning poker, affinity
communications for colocated and/or timeboxing, iteration and release estimating, ideal time
distributed teams, daily stand-ups planning, WIP limits, burn down/up
charts, cumulative flow diagrams,
process tailoring

Agile analysis and design Product quality Soft skills negotiation

• product roadmap, user • frequent verification and validation, • emotional intelligence, collaboration,
stories/backlog, story maps, test-driven development/test first adaptive leadership, negotiation,
progressive elaboration, wireframes, development, acceptance test-driven conflict resolution, servant leadership
chartering, personas, agile modeling development, definition of done,
continuous integration

Value-based prioritization Risk management Metrics Value stream analysis

• return on investment (ROI)/net • risk- adjusted backlog, risk burn down • value stream mapping
present value (NPV)/internal rate of graphs, risk-based spike Metrics
return (IRR), compliance, customer- Including but not limited to: velocity,
valued prioritization, minimally cycle time, earned value management
marketable feature (MMF), relative (EVM) for agile projects, escaped
prioritization/ranking defects

11
Community Guide of the PMI-ACP

Source: PMI.org/Agile

13
Agile History
 Agile Manifesto
• On February 11-13, 2001, at Snowbird ski resort, seventeen
people met to talk, ski, relax, and try to find common ground.

• Representatives from Extreme Programming, SCRUM, DSDM,

Adaptive Software Development, Crystal, Feature-Driven
Development, Pragmatic Programming, and others sympathetic
to the need for an alternative to documentation driven,
heavyweight software development processes convened.
• What emerged from this meeting was a symbolic Manifesto for
Agile Software Development, signed by all participants.

16
 Agile is Not New
Hirotaka Takeuchi DSDN Consortium
& Ikujiro Nonaka Dynamic System
Robert Charette
The New New Development
Taiichi Ohno Lean Development
Product Method Jeff de Luca
Toyota Production Development Game
System Feature Driven
Kanban Development

1943 1985 1995 1997 2000

Hardware Software

1950- 1990 1996 1998 2001

1960s
USAF & NASA
X-15 hypersonic jet
Iterative 1990 - Sutherland & Alistair Cockburn
Incremental Delivery Schwaber Crystal Methodologies
1996 - Beck,
Scrum Framework
Cunningham, Jeffries
Extreme Agile Manifesto
Programming

17
 Agile Practices

PMBOK

Lean

Kanban

Agile is an umbrella term for a group of iterative and

incremental software development methods.

18
 Agile Tools
Process Tools Engineering Tools
VersionOne
Rally Software Ruby
JIRA + GreenHopper Cucumber for
Team Foundation Server ATDD/BDD: http://cukes.info/
Excel RSpec: http://rspec.info/

Kanban Java
AgileZen http://www.junit.org/
LeanKit Kanban http://www.jmock.org/
Kanbanery
.Net
Engineering Tools http://www.nunit.org/
BDD for .NET: http://www.specflow.org/
Continuous Integration http://www.nmock.org/
http://jenkins-ci.org/
http://hudson-ci.org/
http://cruisecontrol.sourceforge.net/

19
 Agile Manifesto Values
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

Individuals & interactions over Processes & tools

Comprehensive
Working software over
documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right,

we value the items on the left more.

Source: www.agilemanifesto.org

20
 Agile Manifesto Principles

Satisfy the Welcome Deliver Collaborate

Customer Change Frequently Daily

Support & Trust Promote Promote

Deliver Working
Motivated Face-to-Face Sustainable
Software
Teams Conversations Pace

Promote Maximize Have

Reflect & Adjust
Technical Through Self-Organized
Regularly
Excellence Simplicity Teams
Source: www.agilemanifesto.org

21
Understanding the Basics
 Flipping the Iron Triangle

Features Cost Date

Value-
Driven
Plan-
$
Driven

Cost Date Features

Source: DSDM

28
 Reducing the Cost of Change

Agile methods support

experimentation &
adaptation by reducing
the cost of change.

This is done by
employing many
concurrent, rapid
feedback loops to
surface and address
risks early.

Source: Examining the Cost of the Agile Change Curve by Scott Ambler

29
 Common Understanding

A document can’t generate the meaning in others that

conversations can.
There is a reason “Individuals and Interactions” is first in the
Agile Manifesto.

? ?
!
We don’t need an
accurate document, we
need a shared
understanding
- Jeff Patton / Agile 2012

30
 Incremental Value Delivery

Analyze
Design
Code
Test
Document
Waterfall Serial Development Deploy $
Invest up front, only realize value at end, assuming value proposition hasn’t changed

Analyze Analyze Analyze Agile Concurrent Development

Design Design Design • Fund incrementally – opt to extend,
Code Code Code redirect or cancel at a very granular level
Test Test Test • Deliver & realize value steadily
• Validate designs with users & customers
Document Document Document
• Continuously adapt to risk and change
Deploy Deploy Deploy
• Integrate early & often

$ $$ $$$
31
 Collaboration and Feedback Loops

Traditional methods only work for so long because…

• No or little feedback before delivery.
• Change not expected.

Why are agile methods being considered?

• Constant feedback loops.
• Change is expected.

32
 Agile is Discipline w/o Undue Burden

Process Burden or Lack of Discipline

• Historically development teams have
faced a false choice in respect to
process
o Overly complex and burdensome
o Or, undisciplined with no controls
• Agile Provides a lightweight, but
disciplined approach for speeding time
to market, improving quality, and
increasing predictability

33
 Exercise – Batch vs Flow Throughput
Four volunteers, please!
Time is set at 2 minutes
Estimate throughput
Round 1 (measure first and last delivery time)
• First person flips 50 coins
• When done with entire batch, pass to next
person
Round 2
• First person flips one coin of highest value and passes to next person
• Keep flipping and passing until done
Round 3
• Each table creates their own rules to maximize coin flow/throughput in least
amount of time

Retrospective

34
 Agile Principles Compared
Key Agile Principles Traditional Waterfall
Focus on Highest Value First All or nothing
Align project, product and team visions by prioritizing by business needs, and Tight coupling & bias toward building out internals in a breadth first
using well architected code, to deliver better quality products faster and fashion means that nothing can be delivered in isolation, even if it’s
cheaper. valuable.

Responding to Change Baseline & Change Control

Acknowledge uncertainty & adapt to both external (market) and internal Constrain or even completely eliminate any significant change other
changes, by modifying plans & approach. Use engineering principles to make than dropping features. Work to initial plans, even when they are
code base easy to modify. proven to be invalid.

Iterative Phased
Use short time boxes to provide a rhythm, continually flow of value to the No rhythm as project is executed using long phases.
customer, and refine deliverables over time.

Feedback & Continuous Improvement Lessons Learned at the End

Use continual feedback to inform plans and modify approach. Feedback is rarely given in time for it to be applied towards improving
processes and project execution.

Small, Integrated Teams Silo Teams with Handoffs

A small team size, and overlap in skills sets, simplifies communications, allows Staff works in functional oriented groups, throwing documentation
everyone to see the big picture, creates self discipline and provides flexibility. and code over the wall.

Technical Excellence / Bake Quality In Inspection

Use TDD , ATDD, refactoring, and other strong engineering principles to Attempt to ensure quality by after the fact inspection.
ensure quality.

35
 Agile is Empirical, Not Definitive
Agile assumes that
baselines may change
significantly during the
project.

In such an unpredictable
environment, empirical
methods should be used
to monitor progress and
direct change, rather than
using definitive methods
to try and predict progress
and stop change.

36
 Agile Uses Rolling Wave Planning
Rolling Wave Planning, used in Agile processes,
embraces the Lean ideal of making decisions at the
last responsible moment, when the most possible
information is available. This maximizes flexibility and
planning accuracy.
Level of Planning Planning Approach
Strategic product line goals Strategic Planning
Strategic product goals Product Planning
Specific problems to solve Lean / Six Sigma
Large functional goals Release Planning
Small, defined work items Iteration Planning
Tactical organization & execution Daily Standup

37
 Layers of Product Planning
Product / Project Iteration / Sprint
What business objectives will
the product fulfill? What specifically will we build?
(User Stories)
Product Goals
How will this iteration move us
Product Charter toward release objectives?
Elevator Pitch Iteration Plan
Development Tasks
Release
How can we release value
incrementally? Story (Backlog Item)
What subset of business
What user or stakeholder need
objectives will each release
will the story serve?
achieve?
How will it specifically look and
What user constituencies
behave?
will the release serve?
How will I determine if it’s
What general capabilities
completed?
(big stories) will the release
offer? Story Details
Release Roadmap Acceptance Tests
Release Plan

38
 Principle - Self-Organized and Empowered

• Top level goal(s) must be

communicated to all levels
of the organization
• Members of the

guide

guide
info

info
organization offer candid
information up the
management ladder.
• Leaders/Managers offer
guidance

guide

guide
info

info
(why and what ≠ how)

39
 Some Basic Terminology
Scrum Extreme Programming (XP) Definition

Sprint Iteration Fixed-length period of time (timebox)

Release Small Release Release to production

Sprint/Release
Planning Game Agile planning meetings
Planning
Product Owner Customer Business representative to project

Retrospective Reflection “Lessons learned”-style meeting

ScrumMaster Coach Agile project manager

Development
Team Empowered Cross-Functional team
Team

Daily Scrum Daily Standup Brief daily status meeting

40
 Some More Agile Terminology

Term Definition

Something cannot be estimated until a development team runs

Spike a timeboxed investigation. The spike itself is a throw-away.
Can include risk, architectural, or any unknown.
An experimental solution that cuts through all the "layers" of
Tracer Bullet the architecture. It is not necessarily time-boxed. It is not intended to be
thrown away.

Kaizen Continual improvement of all areas of a company not just quality.

Value Stream An end-to-end business process which delivers a product or service

More terms… Go to the Community Guide of the PMI-ACP at http://agile.vc.pmi.org/

41
 Meetings Summarized
Session Purpose Timing/Duration Attendees
Iteration 0 Orient Team to project’s business value Start of project Team, PO, SM, Key
and analytical background, the process, Approximately 1-3 Stakeholders & users
and one another. weeks of 2-4 hr
workshops
Release Determine what a Release should include Start of Release PO, SM, Key
Planning and when it should be delivered. 2-4 hours Stakeholders,
optionally Team
Daily Standup Facilitate rapid coordination between Daily Team, SM, PO
Team members, and with PO. 10-15 minutes
Iteration Elaborate, estimate and prioritize highest- Start of each Iteration Team, SM, PO
Planning value Product Backlog items for an 2-4 hours
Iteration.
Iteration Reflect on project & process issues and End of each Iteration Team, SM, PO
Retrospective take action as appropriate. 30-45 minutes
Iteration Demonstrate completed functionality to End of each Iteration Team, PO, SM, Key
Review interested stakeholders & users to show 1-1½ hours Stakeholders & users
progress and gain feedback.

42
 How does Agile Work?
Small Teams with everything needed to deliver
an increment of value
Backlog prioritized by value being delivered
incrementally

At scale, the backlog and products for these

teams need to be coordinated and technical
practices must address the challenges of
integration

43
 Incremental Value Delivery

Analyze
Design
Code
Test
Document
Waterfall Serial Development Deploy $
Invest up front, only realize value at end, assuming value proposition hasn’t changed

Analyze Analyze Analyze Agile Concurrent Development

Design Design Design • Fund incrementally – opt to extend,
Code Code Code redirect or cancel at a very granular level
Test Test Test • Deliver & realize value steadily
• Validate designs with users & customers
Document Document Document
• Continuously adapt to risk and change
Deploy Deploy Deploy
• Integrate early & often

$ $$ $$$
44
 Incremental and Iterative Delivery
Iterating allows you to move from vague idea to
realization. Going from rough to polished
1 2 3 4 5

Incrementing is more about delivery.

1 2 3 4 5

Image Credit: Jeff Patton

45
 Iterations
• Iterations are regularly scheduled, pre-planned, recurring time
boxes. Provide a cadence / rhythm that provides predictability
and synchronization points for planning. The more mature your
process, the shorter the iterations.
• Things we time-box:
o Sprints (or Iterations) - length of time in which work is done
o Releases - Production and Maintenance
o Working Sessions - Release Planning, Sprint Planning, Sprint Review,
Retrospective
• Iterations facilitate incremental development (but incremental
development doesn’t require iterations).

46
Agile Methods
Lean
Kanban
Extreme Programming
Scrum
 What is Lean?

“A production practice
that considers the
expenditure of
resources for any
goal other than the
creation of value for
the end customer to
be wasteful, and
thus a target for
elimination.“
Source: Wikipedia

48
 What is Kanban?
Kanban (看板) literally
meaning "signboard"
or "billboard", is a
concept related
to lean and just-in-
time (JIT) production.
Taiichi Ohno is
considered to be the
father of the Toyota Kanban is a scheduling system that tells
Production System you what to produce, when to
produce it, and how much to produce.

49
 What is Extreme Programming?
• A software development methodology which is intended to improve software
quality and responsiveness to changing customer requirements.

• It advocates frequent "releases" in short development cycles, which is intended

to improve productivity and introduce checkpoints where new customer
requirements can be adopted.

50
 What is “Scrum?”
Scrum is an iterative and incremental project delivery framework.

Source: Wikipedia

51
 Initiating an Agile Project

Iteration 0 Release Planning Session

Brief orientation to the project’s Initial project
business value and analytical Product Backlog planning, to review
background, the Agile process, List of desired functionality initial Product
and the Team. prioritized by business value by Backlog and set
Product Owner. production Release
Project Orientation dates.
• Business case overview Allow a user to create a free
• Business process analysis account. (Priority 1)
• Project scope & objectives Release Schedule
• Initial Product Backlog
Process Orientation Allow subscribers to purchase
• Agile process training music. (Priority 3)
• Sprint/Release cycles
• Definition of “Done”
Team Orientation
Allow user to personalize store
• Team room artifacts
experience. (Priority 9)
• Team norms
• Technical environments,
design, architecture, etc

52
 Agile Project Charter
A useful project charter contains three key elements:
1. Vision: The vision defines the “Why” of the project. This is the higher purpose, or
the reason for the project’s existence.
2. Mission: This is the “What” of the project and it states what will be done in the
project to achieve its higher purpose.
3. Success Criteria: The success criteria are management tests that describe effects
outside of the solution itself.

Additional elements:
Working practices – Planning, estimating, definition of done, tracking progress, TDD
methods
Continuous Integration – integration time limits, breaking the build, code check-in
Code – Paired programming, owning the code, documentation
Iterative and Incremental Development – iteration cycle and deployment cycle

53
Lean
 Lean Portfolio Management
• Corporate strategy operates over years with direct line of sight to priorities
• Optimize the whole
• Manage internal and external dependencies
• Focus on quickly delivering minimal marketable features
• Clear feedback mechanism between business and development
• Creates alignment beyond single teams

Year(s): Set corporate goals and strategies

Quarter(s): Discover and create innovative product strategies from

corporate goals

Month(s): Update Release Plans, Product Backlogs and

Roadmaps
Week(s): Decompose features from Product Backlog
into tasks and deliver working code

55
 7 Principles of Lean

The 7 Principles of Lean

1. Eliminate Waste
2. Create Knowledge
3. Build Quality In
4. Defer Commitment
5. Optimize the Whole
6. Deliver Fast
7. Respect People
Source: Mary and Tom Poppendieck

56
 Lean Process Cycle Efficiency
Process Cycle Efficiency is the key measure of Leanness

PCE = (sum of time for Value Added process steps)

(sum of time for All process steps)
Process map entire value-stream at a high level, drilling down into more detail
only as potential areas of interest are identified

• Value-added: This step in the process adds form, function, and value to the end
product and for the customer.
• Non-Value-Added: This step does not add form, function, or assist in the finished
goods manufacturing of the product.
• Non-Value-Added-But-Necessary: This step does not add
value, but is a necessary step in the final value-added product.

67
 Continuous Improvement
The “Kaizen” Mindset:
1. Everything, not just software

改善
development, can and should be
improved
2. Improvements should be made
day to day
3. The best improvements come
from taking the customer’s point
of view
4. Move from criticism to
suggestion
5. Keep improving, even if things
are working

70
Kanban
 Kanban – High Level
1. Visualize your Workflow
2. Limit Your Work in Process
Example: Mature Requirements Separately
• Instead of figuring everything out for a user story just in time at
Sprint Planning, we can ready them in advance
• The specific process varies, but there is a set of steps to get a
requirement ready
New Acceptance Testable Dev Review Ready for
Candidates PO Approved Decomposed Criteria Example Sprint

10 cards 6 cards 4 cards 4 cards 4 cards 8 cards 12 cards

74
 Airplane Game

Paper Airplane Game

 Team of 5 makes 21 airplanes
 1st Run: Fast as you can
 2nd Run: Flow, Batch size of one
 Consistently better results
– Lead Time: 3X improvement
– Throughput: 10-20% better
– Lower stress
– Easier to manage
 Costs of Over-Utilization
Everything at once
=
many started
few finished

Develop Test
In Process Ready In Process Ready
WIP Limits = Fast
“A system of local optimums is not an
4 slots 3 slots 4 slots 3 slots
optimum system at all” - Eli Goldratt

76
Extreme Programming (XP)
 Agile Engineering Practices
Agile Engineering Practices allow teams to
move fast, be flexible and deliver high
quality software:
• Automated Builds & Continuous
Integration reduce time and effort
associated with manual builds, and risk from
big-bang integrations
• Simple Design & Refactoring keep
incremental development from leading to
poor architectures
• Multi-Level/Automated Testing & Test-
Driven Development reduce testing time
and effort and allow developers to make
changes with confidence
• Pair Programming increases software
quality without impacting time to deliver. Source: Bill Wake, http://www.xp123.com

78
 XP Roles - Coach
XP Coach
• The XP Coach role helps a team stay on process and helps the team to learn. A
coach brings an outside perspective to help a team see themselves more clearly. The
coach will help balance the needs of delivering the project while improving the use
of the practices. A coach or team of coaches supports the Customer Team, the
Developer Team, and the Organization.

• The decisions that coaches make should always stem from the XP values
(communication, simplicity, feedback, and courage) and usually move toward the XP
practices. As such, familiarity with the values and practices is a prerequisite. The
coach must command the respect required to lead the respective teams. The coach
must possess people skills and be effective in influencing the actions of the teams.

• The XP Coach uses many different techniques. The coach is a mentor, working side
by side with team members on their tasks. The coach is a facilitator, helping achieve
more effective team performance. The coach is a conduit, reinforcing
communication within the team and across teams.

79
 XP Roles - Customer

XP Customer

• The XP Customer role has the responsibility of defining what is the

right product to build, determining the order in which features will be
built and making sure the product actually works.

• The XP Customer writes system features in the form of user stories

that have business value. Using the planning game, he chooses the
order in which the stories will be done by the development team.
Defines acceptance tests that will be run against the system to prove
that the system is reliable and does what is required.

80
 XP Roles - Programmer

XP Programmer
• The XP Programmer is responsible for implementing the code
to support the user stories.

81
 XP Roles - Tester

XP Tester
• The primary responsibility of the XP Tester is to help the
customer define and implement acceptance tests for user
stories. The XP Tester is also responsible for running the tests
frequently and posting the results for the whole team to see. As
the number of tests grow, the XP Tester will likely need to
create and maintain some
kind of tool to make it easier to define
them, run them, and gather the results
quickly.

82
 XP Roles – Quick Quiz
1. ______ is responsible for implementing the a) XP Coach
code to support the user stories. b) XP Customer
2. ______ help the customer define and c) XP Programmer
implement acceptance tests for user stories d) XP Tester
3. ______ Helps a team stay on process and
helps the team to learn. Is a mentor, working
side by side with team members on their
tasks
4. ______ writes system features in the form of
user stories that have business value and
defines acceptance tests.

1(c) 2(d) 3(a) 4(b)

83
 Simple Design and Refactoring
Simple Design:
• Code is always testable, browsable, understandable, and explainable
• Do the simplest thing that could possibly work next. Complex design is
replaced with simpler design
• The best architectures, requirements, and designs emerge from self-
organizing teams
Refactoring:
• Remove redundancy, eliminate unused functionality, and rejuvenate
obsolete designs
• Refactoring throughout the entire project life cycle saves time and increases
quality
• Code is kept clean and concise so it is easier to understand,
modify, and extend

86
Risk
 Risk Burndown
Create a risk census during the first sprint planning meeting and then update it quickly
during subsequent planning meetings as new risks are identified or as the
probabilities or sizes of known risks change.
Plot your project risk exposure and
display it with other big visible charts
in your team area.

As with a regular release burndown chart,

we should see a linear drop in risk over the
course of the project.
Source: Managing Risk on Agile Projects | Mike Cohn - Mountain Goat Software

94
 Risk Management

Traditional Risk Management Agile Risk Management

Prepare formal risk management plan Educate the team. Invite them to
determine best approach to manage
Formal risk identification meetings and Team identifies risks in all meetings and
then create Risk Register add to information radiators
Conduct qualitative and quantitative Facilitate the team in a qualitative
analysis. Determine how to respond analysis, determine how to respond,
post results
Periodically review Risk Register and Constantly review risk and responses as
make updates as needed part of all meetings, reviews and
retrospectives

Source: Sliger & Broderick (2008),The Software Project Manager's Bridge to Agility, Addison-Wesley

95
 Implicit Risk Management
Implicitly managing Risk:
• User stories are prioritized by the Product Owner
o Highest value items are attacked first
o Highest risk items are also attacked early

• Iterative delivery ensures that integration and rollout risks are

attacked very early in the project lifecycle

• Technical discipline helps keep a tight rein on development risk

o Automated builds and continuous integration keep code integration and
code quality risk to a minimum

96
 Explicit Risk Management
Explicitly managing Risk:
• Review the Product Backlog
• Identify and list risks by impact
(High/Medium/Low) and probability
(High/Medium/Low)
• Provide a mitigation plan with clear
responsibility
• Create task cards for risk mitigation
items
• Insert into Product Backlog and/or
Sprint Backlogs; or track on Risk Board
Agile Risks, Agile Rewards, Smith and Pichler, Dr. Dobb’s 2005

97
Agile Requirements
 Work Organized by Value
Work in Agile projects is organized by Units of Value, rather than
by Architectural Layer.

Feature / User Story 1 Feature / User Story 2 Feature / User Story 3

User Interface Layer

Business Logic Layer

Persistence Layer

99
 User Stories at a Glance
Key Characteristics Product Backlog User Story
• High-level descriptions of desired As a user I can create an account.
functionality and goals
• Implement “vertical slices” of the Estimate 21 Points
Priority 1 (High)
system’s functionality
• “Contracts for conversation,” not
all-inclusive requirements As a user I can enter a user
• User stories wait in the Product name.

Backlog until pulled into the Sprint Estimate 4 points

Backlog Priority 1 (High)

• Contain Acceptance Criteria to

define “Done” As a user I can enter Sprint Backlog
password. User Stories
Estimate 8 points
Priority 1 (High)

100
 From User Stories to Tasks

User Story Tasks

As a user I can enter a • Design user interface
password. • Develop CSS/HTML
• Create database fields
Estimate 8 points • Develop validation criteria
Priority 1 (High) • Write test cases
• Code test fixtures
Acceptance Criteria On back…
• Unit testing
• Acceptance testing
• Password match validated • Usability testing
• Contains special characters • Write online help text
• Minimum 10 digits
• Cannot be text only

101
 User Story Template
User Role (Who?)

As a <type of user>, Desired Function (What?)

I can <immediate goal>
so that <business outcome>.
End Result (Why?)

Who, What, Why…

what’s not here?
102
 User Story Acceptance Criteria
Acceptance Criteria help to set scope and define what
Done means for a given User Story.

As a user, I can cancel a reservation.

• Verify that a premium member can cancel the same

day without a fee.
• Verify that a non-premium member is charged 10%
for a same-day cancellation.
• Verify that an email confirmation is sent.
• Verify that the hotel is notified of any cancellation.

103
 What Makes a Good Story?
Circle which attributes
make a good story and Independent
then discuss as the group
Negotiable

Valuable

Estimatable Creative

Small Testable
Source: Bill Wake

104
 Pre Release Life of a User Story
User Stories Created Prior to Acceptance Criteria Created
Release Planning Prior to Release Planning

As a user • Phone # in US format, contains no

I want to create an account alpha characters, minimum 10 digits
• First name, Last name and email
address required
Estimate 5-Points • Email specified in standard format
Priority 1 -High • Etc.
(Created at Release Planning)

Testable Examples (ATDD) Created Prior Sprint Tasks Created

to Sprint Planning at Sprint Planning
Name Phone Email Valid • Design UI Mock Up
John Smith 215-555-1212 [email protected] TRUE • Write online help text
Smith 215-555-1212 [email protected] FALSE • Develop CSS/HTML
John 215-555-1212 [email protected] FALSE • Develop validation criteria
215-555-1212 [email protected] FALSE • Create database tables
John Smith [email protected] FALSE • Code test fixtures
Smith [email protected] FALSE • Code
John [email protected] FALSE • Perform testing

105
 Beyond User Stories
User Stories aren’t the only way to develop, express and
elaborate requirements in Agile. Some complementary
tools & methods include:
• Essential Use Cases
• Low-fidelity prototyping
• High-fidelity prototyping

The best approach will be determined by your team and

the problems at hand.

106
 Low-Fidelity Prototyping in Agile
Low-fidelity prototyping is a
fast, cheap, easily iterated,
collaborative way to test various
concepts & approaches.
Tools
• Paper sketches and collages
• Whiteboard drawings

Applications
• Concept design: to explore different metaphors and design strategies
• Interaction design: to organize screen structure & flow
• Screen design: for initial screen layout & design
• Screen testing: to refine screen layout
Source Adaptive Path for Sketchboard example

107
 High-Fidelity Prototyping in Agile
High-Fidelity prototypes are detailed,
interactive and reusable means of
simulation.

Tools:
• Photoshop, Visio, Powerpoint
• Flash, iRise Studio, Serena ProcessView
• WPF, XAML, XUL…

Applications:
• When stable requirements support reuse
• To test complex interaction scenarios
• To finalize detailed designs
• As inputs to a Sprint

Source: iRise Studio, www.irise.com

108
 Agile Requirements
1. In general, we can view the maturation of a) build
a need (expressed as a user story) as b) domain knowledge
having enough information to prioritize,
__________ and ___________. c) estimate (test)
2. The user story format has three parts: d) outsiders
“as a”, “I want to” and “_________.” e) so that
3. Acceptance criteria is written for team
members and, as such, assumes a level of
f) testable example
existing ___________.
4. Acceptance criteria is incredibly useful
but a ___________ will often provide
significant additional clarity.

1(c) (a) 2(e) 3 (b) 4 (f)

109
 Agile Requirements
5. A ___________ defines how the software will g) complexity
be implemented; it can define the external
behavior, ___________ design, or both. h) designs
6. As defined in this training, a specification builds i) internal
on a requirement with additional context,
conversations and ___________. j) lightweight
7. A specification should be ___________, k) specification
defining just enough to help the team build
confidently within the sprint. l) vary
8. The appropriate level of detail required in a
specification will ___________, depending on,
among other things, the ___________ of the
requirement, the domain knowledge of the
team, and the requirements’ similarity to what
has already been built.
5(k) (i) 6(h) 7 (j) 8 (l) (g)

110
Agile Estimation
 Agile Estimation Levels, Units and Sequences
High Level – Affinity Story Level – Planning Poker
Story Points
o Purely relative measure of complexity (2 is half as hard as 4)
o Variability averages out across many stories
o Don’t decay over time

Scales with increasing gaps between elements are preferred

o Fibonacci: 1, 2, 3, 5, 8, 13
o Doubles: 1/2, 1, 2, 4, 8, 16
o “T-Shirt Sizes:” S, M, L, XL, XXL
Traditional project estimation
approaches may be necessary
Avoid false precision to avoid for initial scoping, but should
false expectations. rapidly be replaced by
empirical observation of Team
output capacity (velocity).
112
 Agile Estimation Essentials
1. Use more than one person. By engaging the team in the estimation process, we gain the benefits of
additional insights and consensus building.
2. Use more than one approach. Use multiple estimation approaches (comparison to similar projects,
bottom up, user story points, etc.) and look for convergence between multiple approaches to reinforce
likely estimate ranges.
3. Agree on what “It” and “Done” means. Make sure everyone is estimating in the same units, have the
same assumptions and are based on standard developer ability/effort.
4. Know when to stop. Balance estimation effort against the diminishing returns and false accuracies of
over analysis.
5. Present estimates as a range. Estimates are often poor predictions, and should be noted as such.
6. Defend/explain estimate range probabilities. Educate stakeholders about the relative likelihood of
hitting optimistic/pessimistic estimates.
7. Don’t reserve estimating for when you know least about the project. Estimation should not be
reserved for only the beginning of projects.
8. Be aware of common estimation omissions. Don’t overlook commonly missed tasks, and use
retrospectives to inspect project-specific issues.
9. Embrace reality early. Don’t under-estimate the load of maintaining and refactoring a growing
codebase.
10. Review, Revisit, Remove Head from Sand, Repeat. Adjust project forecast based on empirical
observation of throughput.
113
 Affinity Estimating

Participants: Whole team

Multi-team environment: Work together!

Process: Cards are placed in a stack on the table

• Product Owner explains the top card
• First team member places this card on Smaller Larger
table by size (left smaller, right larger)
• Next team member either repeats process with next card, or moves an existing card
to a new position, with an associated explanation
• Process repeats until all cards are placed and grouped, and no more movement is
desired
• Each group is labeled with its estimate

114
 Exercise – Relative Dog Sizing
• Clifford the Big Red Dog
• Marmaduke
• English Bulldog
• Chihuahua
• Pug
• Scooby-Doo
• Great Dane

Rules Point Estimating:

Team decides scale
Discuss criteria for complexity
Find the reference point Based on Mike Cohn’s dog points
Estimate size for remaining items

115
 Agile Estimation – Planning poker
“Planning Poker” is based on “Wideband Delphi” convergent
estimation techniques.

How to do it:
1. Each estimator (someone who could possibly be doing the
work in question) is given a deck of cards, each card has a
valid estimate written on it
2. A moderator reads a story and it’s discussed briefly
3. Each estimator selects a card to represent her estimate
4. Cards are turned over so all can see them
5. Discuss differences (especially outliers)
6. Re-estimate until estimates converge (or don’t!)

116
 Planning Poker Example

Estimator Round 1 Round 2

Susan (Dev) 3 3
Vijay (QA) 8 5
Ann (BA) 2 5
Bill (Dev) 5 5

117
Scrum
 Scrum – 50,000 Foot View

Release Sprint Sprint Sprint

Planning Planning Review Retrospective

119
 Scrum Roles & Responsibilities
There are only three roles defined in Scrum:

Product Owner ScrumMaster The Team

• Owns Product vision • Responsible for • Small group containing all
• Defines features, decides facilitating process necessary project skills
on release date and • Focuses Team and • Focuses on steady
content protects them from delivery of high quality
• Responsible for market external interruption features
success • Looks for ways to • Generates options for
• Prioritizes features enhance productivity delivery
according to market value • Assists Product Owner in • Manages own work
• Can change features and leveraging Scrum within Sprints
priorities every Sprint

120
 Artifacts of Scrum

• Product Backlog
Prioritized list of valuable items to
deliver during the project.
• Sprint Backlog
List of committed items to be
addressed within a Sprint.
• Burndown/burn-up Chart
Visual aid for tracking team
progress and forecasting
expected completion dates.
• Velocity Chart
Tracks rate of feature
completion.

121
 Scrum Milestones

Product
Backlog
• ____________
• ____________
• ____________
• ____________ Sprint Sprint Sprint Sprint Sprint Sprint
• ____________ Backlog Backlog Backlog Backlog Backlog Backlog
• ______ • ______ • ______ • ______ • ______ • ______
• ______ • ______ • ______ • ______ • ______ • ______

U U U U U U
S
Initial S
1
S
4
S
6
S
1 4
S
7

Planning U U U U U U
Release Planning

Release Planning

Release Planning
S S S S S S
2 5 7 2 5 8

U U U U
S S S S
3 8 3 6
Sprint Planning

Sprint Planning

Sprint Planning

Sprint Planning

Sprint Planning

Sprint Planning
F1 F2 F1 F4 Release 2
Release 1
F3 F2 F5 F1, F2, F3
F1, F2, F3
F4, F5, F6
F3 F6

122
 Scrum Milestones

Features User Stories MMF

123
 The Scrum Sprint Cycle

Complete Sprint Backlog

Sprint Planning Team works on highest-value functionality until it
Elaboration, estimation and meets jointly defined Acceptance Criteria.
prioritization of highest-value
User Stories.
Daily Scrum (or Standup)
15-minute status and risk management meeting for

Sprint Execution
Sprint Backlog Team & Product Owner.

Allow a user to enter a Sprint Review

login & password. Team demonstrates completed functionality to
interested stakeholders, gathering feedback.

Allow a user to enter

personal information. Production Release (Optional)
Generally occurs when a useful group of related
functionality has been completed.
Allow user to enter billing
information. Retrospective
Team reflects on project & process and takes action
as appropriate.

124
 Cadence & Synchronization
Instead of wasting time coordinating numerous meetings and dates…

Use a cadence of recurring working sessions to synchronize and simplify planning

while providing continuity
125
 Small Collaborative Teams
Instead of cube farm, organized by function…
We collaborate via flexible roles and simple rules to
decentralize decision making and get work done.
Before After

126
 From Product to Sprint Backlog
Product Backlog Sprint Planning Sprint Backlog Sprint
PB Item Priority Points SB Item Priority Hours
Team pulls and
User Story High 5 User Story High completes Tasks
until each User
Top priority Task 1 4 Story is done.
User Story High 8
stories are Task 2 12
User Story High 3 discussed and
decomposed Task 3 6
User Story Med 13 into Tasks for User Story Med
the Sprint
User Story Med 8
Backlog.
User Story Med 5 Task 1 9

User Story Med 13 Task 3 2

User Story Low
User Story Med 8

User Story Med 5 Task 1 5

User Story Low 21 Task 2 2

User Story Low 13 Task 3 7

127
 Tracking Work in a Sprint
Cards move left to right, downstream, if there is space.

Sprint Backlog In Progress Completed

Cards move left to right,
assuming there is space, then…
10 cards 6 cards

Sprint Backlog In Progress Completed

From Sprint Backlog to In Progress,

if there is space, and…
10 cards 6 cards

Sprint Backlog In Progress Completed

From In Progress to
Completed.
10 cards 6 cards

128
 Scrum Process Review

1. The ___________ ensures that a) user story

requests are expressed in user
story or other appropriate b) product owner
format and placed in the
___________. c) product backlog
2. The ___________ provides story d) prioritize
point estimates for each
___________. e) releases
3. Product owners ___________
user stories (PBIs), then, with f) team
input from the team and other
stakeholders, sequences user
stories into ___________.

1(b) (c) 2(f) (a) 3 (d) (e)

129
 Scrum Process Review

4. At the end of each ___________ g) sprint

the team demonstrates
_____________ they do this at h) sprint review
the ___________. i) sprint retrospective
5. The total story points estimates,
for those stories that were j) velocity
completed in a sprint, are added
k) working software
together to provide us with the
___________ for the sprint.
6. The team holds a ___________ to
evaluate how well they’ve done
and what changes could be made
to the process to further improve.
4(g) (k) (h) 5(j) 6(i)

130
Roles & Responsibilities
Product Owner
 Product Owner Responsibilities
Manage the return on investment (ROI)
• Establishes baseline target ROI
• Measures project against this baseline
• Prioritizes product backlog to maximize ROI
Guide product development
• Establishes, communicates and nurtures the vision
• Knows what to build and in what sequence
• Tunes the vision with the team
Call for releases
• Decides when to call for release of a potentially shippable product increment
• Can shift a release forward to maximize ROI based on new knowledge

133
 An Army of One?
Busy Product Owners need not – and should not – act alone.
Some of the roles that can assist:
• Business Analysts help to define business needs and elaborate them for the
rest of the Team
• Developers provide available execution paths and describe their respective
costs and benefits
• User Experience experts and marketing resources help to elicit and explain
end user needs and desires
• Other Business Stakeholders to get a wider representation of needs from
across the organization

Product Owners represent

many constituents with a single voice.

134
 Shared Understanding of Value

The Product Owner helps to spearhead a Shared Vision,

but the whole Team should understand it:
• Communicate & elaborate early conceptual & visioning work
through Sprint (Iteration) 0.
• Involve Team in translating User Needs into Product Functions
• Involve Team in development of clear Goals
• Directly involve Team in feedback loops
• Provide direct exposure to end users

135
 Reluctant Product Owner

Sarah, the client product manager for your

development project, has little interest in being a
product owner. “We’ve given you the specification
of exactly what we want done,” she declares. “Just
do your thing. I know you guys are good!”

What do you do?

136
 Defining “Ready”
What must be in place for your project teams to plan
and estimate 2-3 weeks worth of work?
(e.g. wireframes, detailed acceptance criteria, key stakeholder approval…)

Sprint

Ready In Process Done

137
 Definition of “Ready”

Example of a Definition of Ready

Analyst – User story sufficiently defined and mapped
from requirements
Tester – Acceptance criteria developed
Developer – User story is estimated and no known
blocking dependencies exist within the sprint

138
Vision and Goal
 A Typical Agile Pipeline
>4 Sprints Ahead ~2 Sprints Ahead Current Sprint

Ideation Maturation Execution

Market Trends User Story Decomposition Sprint Planning

Prototypes User Story Maturation Task Estimation
Focus Groups Acceptance Criteria Daily Standups
User Experience Test Cases Software Development
Basic Workflows Dependencies Testing
Vision Story Mapping Burndowns
Business Outcomes Prioritization Documentation
Release Timing and Goals Epic Estimation Product Demos
Product Architecture Backlog Development Retrospectives
Epics and Features

Marketing/Sales, Product Product Owners, Leads, UX/Analysts, Dev

Management, Product Architects, Dev Leads, QA Team Members
Owners, Architects Leads, UX/Analysts

140
 Requirements Breakdown Structure
With Scrum, we refine requirements over time, from a high level
Vision down to User Stories and tasks that can be executed in a Sprint.
• At each level, items can break down further into siblings, so one Epic can become two.
• The exact breakdown is often unclear; is this
a Feature or an Epic? In reality, the
exact breakdown is not important.
Vision
• The names may also vary, so
“User Story” or “Story” are
Goal / Outcome Goal / Outcome
often used interchangeably.

Epic Epic

Feature Feature Feature Feature Feature

Story Story Story Story Story

141
 Agile Estimation Basics
1. Estimate relative level of effort for each feature
o Takes into account complexity of work, effort, etc.
o Uses relative units (e.g. A is half as hard as B)

2. Measure “Velocity” to set Team capacity

o Takes into account external interruptions, technical
surprises, developer skill level, domain knowledge, etc.
o Work actually completed over time gives accurate data to
determine capacity for a Team

Velocity requires stability to be accurate.

142
 Definition of “Done”
Example of a Definition of Done
• Analyst – Working system reviewed and User Story accepted via
Automated Test or Manual Inspection
• Tester – Test cases pass. All critical and high severity bugs fixed
and other bugs identified and tracked
• Developer – Deployed to test environment and Code Review
complete

143
 Velocity Calculation
Story Estimate Status at End of Sprint
As a Prospect, I can submit an application. 2 Pts* Complete
As a Policy Holder, I can update my account 5 Pts Complete
information.
As an Account Representative, I can view a 8 Pts Complete
Policy Holder’s information.
As an Underwriter, I can approve or reject 5 Pts 1 Pts Remaining
applications.
Total Sprint Velocity 15 Pts

* Pts = Story Points

Next Sprint,
15 Pts would be our
projected capacity.

144
 Defining Key Metrics in Agile

Metrics fall into two general categories:

Business Value
o ROI, IRR, NPV Tips:
• Measure outcome, not output
o % cycle time reduction • Measure only a few things
o Customer satisfaction (NPS) • Ensure commonly understood
operational definition and
Diagnostic measurement plan
• Target specific questions and
o Velocity audiences

o Successful builds per iteration

o Defects across iterations
o Code coverage

145
 Planning Releases
Velocity = 14 points per Sprint

Sprint 1 Sprint 4

Story A 5 Story B 3 Story K 3 Story L 8

Story C 5 Story G 1 Story M 2

Sprint 2 Release 1
Story D 2 Story E 5 1. Guess a starting velocity (14 in this case)
2. Choose which stories must exist to
Story F 2 Story I 5 Release and see how many Sprints are
needed, or…
Work backwards from the Release date to
Sprint 3
fit as many high-value stories as possible
Story H 8 Story J 5 3. Adjust the scope within the Release as
true Velocity becomes apparent

146
 Estimating Dates with Velocity
Based on the velocity chart below, in what iteration can the
business expect 33 more story points completed?

Velocity stabilizes as
business & technical
domain knowledge
increase and teams
move from forming &
storming to
performing.

147
 Estimating Cost
If each sprint costs $20k, what would be the project cost at the
end of iteration 15?

148
 Agile EVM instead of Velocity
When you are mandated to use EVM
Apply the 0/100 method to measure completion of Stories and Tasks.
It is possible to maintain ANSI/EIA-748 reporting compliance
• Replacing velocity with EV metrics
• Creating measures of budgeted cost of work performed (BCWP) using "testable stories"
• Establishing the Budgeted Cost of Work Scheduled (BCWS) baseline at the beginning of
each iteration
• Capturing Actual Cost of Work Performed (ACWP) through a time keeping system
• Computing Cost Variance, Schedule Variance from the three base earned value metrics
• Computing Estimate at Completion (EAC) and Estimate to Completion (ETC) from these
base metrics as well.

1. If you know why you use EVM now, the same applies to AgileEVM
2. Use the iteration as the unit for basing calculations

149
 Sprint Planning Sample Agenda
• Review velocity and set Sprint capacity
Identify anything unique about the coming sprint (vacation, holidays, etc.)
• Select Sprint Goal (Optional)
• Select top-priority User Stories from Product Backlog
Select slightly more than capacity, aligned with Sprint goal as appropriate
• Discuss User Stories to create Tasks & Acceptance Criteria
• Estimate User Stories
Base on individual task estimates, sticking to about 1-8 hours/task
• Commit to User Stories
Select until capacity is reached, with some backup stories discussed in case Team
finishes early

150
Identifying & Modeling
Users & Customers
 Applications of User Models
Prioritization and Socialization
o Prioritize user types each release as you
would functionality. Knowing high
priority users helps you identify high
priority functionality.
o Post them in the area your team works
to help team members empathize with
target users and make better tactical
design decisions.
Focusing Testing & Evaluation
o Identify user test subjects.
o Identify alpha/beta test subjects.
o Compare them with your eventual
actual users to identify bad assumptions
and to add new user constituencies.

152
 Users vs. Customers
Users interact directly with the system
They are important to understand, because:
• Knowledge of current usage patterns helps to design
better, more usable systems.
• Unsatisfied users will work around the system, nullifying
its advantages and eventually eliminating it.

Customers make buying or adoption decisions

They are also important, because:
• They have their own wish lists that may have little to do
with their users’ needs.
• They make the purchasing decisions, so if they aren’t
happy, you won’t get in the door.

153
 Succinct User Roles
Less detailed descriptions can also work
Nurse Admitting New Patient to Ward
Context Busy, noisy hospital.
Environment & basic
responsibilities of the role
Characteristics • Uses the application only several times a
Patterns of interaction, week.
behaviors, and attitudes • Gets trained at in-service once a year.
• Has access to peers to ask questions.
Criteria “Get the data entered as quickly as possible
Key objectives of the role without making any mistakes!”

154
 One Step Further - Personas
Personas take user roles one step further.
o Represent our current or desired audience.
o Provide a name, a face, and a description to a
particular “user role.”
Level of detail
o Some believe in creating a small number of very
detailed personas. These often over specify.
o Lightweight personas will suffice for most
situations.
“Extreme Character Personas will lead you to stories, you
would be likely to miss otherwise”
User Stories Applied by Mike Cohn

155
 Example Personas
Here are some example personas
Peter the Programmer
“I’d like to get a better handle on test driven development and refactoring.” Peter’s
company has just started using agile development. While he’s been a developer for a long
time, he’s not used agile practices like TDD.

David the Agile Developer

“I've been using TDD, refactoring, and continuous integration for many years now. I want to
see what's next.” David is a strong engineer that started with Extreme Programming
practices about 2001. He’s proficient at most agile engineering approaches and always on
the lookout for new cutting edge techniques. The other engineers in his department look
to him for ideas and advice.

Tara the Tester

“How do I find time in an Agile process to test effectively?” Although Tara’s been a tester
for a long time, she’s been working in an agile team for only a few months. Testing is a real
challenge in an agile environment. Tara’s finding she needs to be part programmer to use
the automated testing framework her company has adopted for acceptance tests. Some
days Tara wishes her company would go back to waterfall development.

Source: Based on “Personas” from Agile 2009

156
 Personifying Your Users
A bit more detailed persona give personality to User Roles,
helping the Team & Product Owner relate better to them.
Night Nurse • Needs to be based on
Robin study of human behavior
Robin leaves for work at 6pm, after • Usability Testing
sleeping during the day. She works a
• Observation
7pm-7am shift in Labor & Delivery,
caring for prospective mothers and • Interviews
their babies. It is an uneven shift; • Surveys
sometimes chaotic and busy,
sometimes slow. There are 16 other • Empathy helps to guide
nurses in a given shift, and they design decisions
coordinate their activities in a central • Should not be taken too
room. Bad IT makes Robin grumpy.
literally

157
ScrumMaster
 ScrumMaster Responsibilities
A ScrumMaster:
• Removes barriers between development
and the customer so the customer drives
development
• Teaches customers how to maximize ROI
and meet their objectives through Scrum
• Enforces the values and practices of Scrum
• Improves productivity in any way possible
• Introduces engineering practices and tools to help ensure
that each increment is potentially shippable

159
 What do you do?

The ScrumMaster or Agile Project Manager wants

one one-hour weekly status meeting instead of
daily 15 minute stand-ups because one meeting is
“more efficient.”

What do you do?

160
 Ethical Leadership
 Egoism: When a person acts to
create the greatest good for
himself or herself.

 Utilitarianism: The idea that

the moral worth of an action is
determined solely by its
usefulness in maximizing utility
or minimizing negative utility.

 Altruism: The opposite of

egoism, a person’s primary
purpose is to promote the
best interests of others.

Source: Based on Domains of Ethical Theories from Leadership Theory and Practice

161
 Servant-Leadership
 Listening
 Empathy
 Healing
 Awareness
 Persuasion
 Conceptualization
 Foresight
 Stewardship
 Commitment to the growth of people
 Building community

162
 Failure – End, or Means?
ScrumMaster Encourages:
• Forthrightness
• Blameless observations
• Failing & learning fast

ScrumMaster Discourages:
• Defensiveness
• CYA retrenching
• Fear of failure

163
 Typical ScrumMaster Activities
• Ensure everyone is doing what
they have agreed to do
• Facilitate Scrum sessions
• Look for ways to improve
productivity and collaboration
• Assist the Product Owner with
the Product Backlog
• Use all of your senses, including
common sense, and remember
that you have no authority

“A dead ScrumMaster is a useless ScrumMaster”

- Ken Schwaber

164
 Dialogue – Hats of the ScrumMaster

• Can a ScrumMaster also be a team member?

• Can a ScrumMaster also be a product owner?
• What potential issues might arise from these
scenarios?

165
 Group Discussion – PM vs. SM
What are the key differences between “traditional”
PMs and “Agile” PMs or ScrumMasters?
• What project activities does a traditional Project
Manager typically handle?
• How are these different from the activities required of
a ScrumMaster?
• Are there issues with wearing
these two different hats?

166
 Facilitation Methods
• Set the standard for the discussion.
• Make the environment a priority.
• Be mindful of timing issues.
• Articulate the purpose of the discussion and
its significance to the group.
• Make use of various techniques/tools to keep
the discussion moving when tension arises or
discussion comes to a halt.
• Try using an Agile game like “speedboat”
• Pay attention to group behaviors.
• Be relaxed and have a sense of humor to
make sure discussions are enjoyable as well as
educational.
• Seek consensus with methods like dot voting
or fist of five
167
 Consensus Workshop Method “Sailboat”
The goal is to identify factors that
are preventing you from
moving forward. In this case
the sailboat represents your
group or organization. The
issues holding it back are
symbolized by anchors.
Anything propelling you
forward is wind in your sails.

Based on Speedboat by Luke Hohmann of Innovation Games

168
 Facilitating Group Decision Making
1. Build the foundation
• Establish ground rules, roles and responsibilities
• Frame the problem, constraints and desired outcome
2. Explore possibilities
• Generate options
• Solicit expert opinions
• Storyboard potential solutions
3. Seek agreement
• Show of hands
• Roman vote
• Fist of Five
• Multi-voting

169
 Active Listening
 Face the speaker
 Maintain eye contact
 Minimize external distractions
 Respond appropriately
 Focus solely on what the speaker is saying
 Keep an open mind
 Avoid letting the speaker know how you
handled a similar situation
 Wait until they finish to defend yourself
 Engage yourself

170
 Emotional Intelligence
Unlike your Intelligence Quotient (IQ) which is pretty well fixed at an early age,
your measure of Emotional Intelligence, or Emotional Quotient (EQ) can be
easily developed throughout your life.

Personal Competencies Social Competencies

With Me With Others
SELF-AWARENESS EMPATHY

What I See
Knowing one's internal states, Awareness of others' feelings,
preferences, resources, and needs, and concerns. Self Social
intuitions Awareness Awareness
MANAGING EMOTIONS SOCIAL SKILLS
Managing one's internal states, Adeptness at inducing

What I Do
impulses, and resources. desirable responses in others.
Self- Relationship
MOTIVATION Management Management
Emotional tendencies that
guide or facilitate reaching
goals.

171
 Five Levels of Conflict and Resolution
Level 1: Problem to Solve
• The normal conflict that occurs when team members have differences of opinions but
can work through those for the greater good of the team and project.
• Seek collaboration – Seek a win-win situation
• Consensus. Learning where every team member’s head is with regard to the issue
and, in time, arriving at a decision everyone can back.
Level 2: Disagreement
• Personal protection trumps collaboration. Language is guarded and open to
interpretation.
• Support – Empowering the other to resolve the problem.
Level 3: Contest
• The goal is to win. It is no longer about resolution but about coming out on top.
• Accommodate – Yielding to the others view when the relationship is more important
than the issue. Negotiate and get factual. Gather data to establish the facts.
Level 4: Crusade
• The battle lines have been drawn and each “side” does not believe the other side will
change.
• Focus on lowering the level of conflict. Use “shuttle” diplomacy and deescalate.
Protecting one’s own group is the focus.
Level 5: World War
• It is not enough that the person wins but that they destroy the other person.
• Do whatever is necessary to prevent people from hurting one another. Source: Lyssa Adkins Coaching Agile Teams

172
 Negotiations
• Analyze the situation.
• Differentiate between wants and needs – both theirs and
yours.
• Focus on interests and issues rather than on positions.
• Ask high and offer low, but be realistic.
• When you make a concession, make clear you are yielding
something of value. And don’t just give in.
• Always make sure both parties feel as if they have won. This is
a win-win negotiation. Never let the other party leave feeling
as if he or she has been taken advantage of.
• Do a good job of listening and articulating.
Source: PMI PMBOK® Guide 4th Edition Section G.8

173
 ScrumMaster Review
1. The ScrumMaster (SM) removes a) Bill Lumburgh
__________ between development and
the customer. b) barriers
2. __________would not have been a very
good ScrumMaster. c) build
3. __________ are altruists
4. With level 1 conflict, we seek
d) seek
__________ situation. e) servant-leaders
5. When facilitating a group, a
ScrumMaster should ___________ a f) win-win
foundation, explore the possibilities, and
__________ agreement. g) aware
6. You need to be __________of others'
feelings, needs, and concerns to possess
empathy.
1(b) 2(a) 3(e) 4(f) 5(c)(d) 6(g)

174
The Team
 Collaboration Exercise
Steps Rules:
1. Start point = End point (person)
1. Intro + Rules
2. Process the most work possible
2. 2 minute prep time
3. Balls must have air time when
3. Get an estimate being passed

4. Create velocity chart 4. Balls may NOT be passed

directly to your neighbor on
5. 2 minute iteration the left or right
5. Balls must be touched by each
6. 1 minute improvement and every person
& new estimate 6. Balls cannot be processed as
one group (the bag/box)
7. Repeat 5 times
7. Balls left on the floor at the end
8. Retrospective of an iteration are waste and
will be subtracted from your
Thank you Scott Dunn, Boris Gloger
production total

176
 Exercise - What did we learn?
 The inspect and adapt cycle can
be used to improve a system of
production.
 A system has a natural velocity.
 Velocity of a team stabilizes
because of the team’s system
and because the team learns
how to work together.
 Having a large team makes
communication more difficult
 If you want to go faster, you
have to change the system.

177
 Extended Scrum Team

Traditional Silos Customer PM BA

BA
Analysts
Designer
Designers
Developer
Developer
Developer
Developer
Devs
Tester
Tester
Testers

Product Release
The Core Team Owner Manager

ideally consists of
5-9 dedicated Product
BA /
Capacity
Planner
Owner
members (7 +/- 2) Architect Tester
BA
The Extended
Designer Core Team may contain
Risk SM Prod. many additional
Assessor
Team members, each
(EXAMPLE)
Developer /
BA Tester
playing an
Developer important role, but
Tech
Ops
Security they are typically
not dedicated to
Business
Sponsor the effort.

178
 Team of Specialists
The analyst on the project wants to work one
sprint ahead so that the analysis is ready when
the programmers need it.
The tech writers want to work one sprint behind
so that they are “more efficient.”

What do you do?

179
 Common Team Dysfunctions
• Lazy Members – Not all team members will always be equal
contributors. Focus on leveraging strengths, and encourage the
team to help poor performers.
• Consensus Quagmires – Group decisions can benefit from
perspective and suffer from dilution. Use facilitation techniques
to foster rapid, inclusive decision making.
• Hero Culture – Teams must have shared goals, not be driven by
individual desires. Roving leadership is an ideal state.

What are some other dysfunctions you’ve seen?

180
 Team Motivation
 Provide Feedback
You can’t expect your team to operate
in a vacuum.
 Recognize Performance
Give constructive feedback so
they can meet your
expectations. Reinforce what you like
so they can continue to meet those
expectations or exceed them.
 Negotiate
Recognize that some team members will not feel comfortable with some goals set for
them. Negotiate realistic outcomes.
 Persuade
Get to know each of your team members personally and find out what motivates
them.
 Respect
Respect is fundamental in any relationship. You will get the very best from people if
you have mutual respect.

181
 Dialogue – High Performance Teams
Discuss answers to the following questions:
• Have you ever been in a high-performance team?
• What characterized that experience?
• Could you replicate it effectively in Agile projects?

182
 Self Organization
Self-organization refers to a process in which the
internal organization of a system, normally an open system,
increases automatically without being guided or managed by
an outside source. Source: Wikipedia

183
 Self Organizing Teams

Self-organizing teams: Self-Organizing Teams

are Characterized by:
• Exhibit a high degree of
collaboration
• Small team size
• Operate with a high degree of • Dedicated resources
trust and autonomy • Customer value orientation
• Individual competence
• Work towards high performance
• Sustainable self-discipline
• Produce measurably great results • Intense collaboration
• Are very fulfilling to work on • Easy information transfer
• Low decision feedback time
• Constant learning &
interaction

184
 Team Diversity
We want a broad model of Values
Beliefs
Risk Aversion
diversity based on style, Emotional Intelligence
Motivation
not just demographics Change Readiness

• Change Readiness Religion

Communications Style
Work Experience
• Emotional Intelligence Geographic Location
Family Status
• Risk Aversion Education and
Qualifications

• Motivation
• Work Style
Age
We want diversity as Gender
Race
expressed in outer rings Sexual Orientation
Ethnicity
Mental Abilities
Physical Abilities

185
 Roles of the Team
The Team
• Works cross-functionally
(reduce handoffs !)
• Shares roles to get the work done
(i.e. generalizing specialist)
• A developer may write user documentation
• A business analyst may perform testing
• A tester may create graphics
• Develops the detailed task list and the estimates
• Volunteers for work (is not tasked)
• Raises issues to the ScrumMaster
• Assesses performance and makes process recommendations

186
 Self Organizing Principles
Self organizing principles guide a team so they can
operate with minimal management control
o As a team member, I will contact the ScrumMaster if I see a tweak
that can be made to a feature, that will maintain it’s business
value, while reducing time, cost or risk associated with
implementing that feature
o As a team member, when I complete my work, on a task, I will
either help another team member, or start a new task, depending
on what will most likely allow us to deliver the maximum value in
a Sprint
o As a team member, I will provide honest and open feedback to my
peers, to the ScrumMaster, to the Project Manager, whenever
that feedback will help the performance of the team

187
 Teams are Cross-Functional

This is not a cross-functional team:

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Analysis Coding Testing
Analysis Coding Testing
Coding Testing
Analysis Coding Testing

This is.
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Analysis Analysis Analysis

Coding Coding Coding
Testing Testing Testing

188
 Caves and Commons Layout
We all need a place to call home
Burndown Information
Chart Radiator

• Common area for collaboration

o Open flow of information

• Caves for privacy

Cubicles
Cubicles
o Intense problem solving
o Creative solitude
o Private phone calls
o Research
o Rocking silently and weeping

Whiteboard Covered Wall

189
 Shared Visual Workspace
• Information transfer
maximized through
collocation
• Constant face-to-face
communication and
collaboration
• Allows for Osmotic
Communications
• Self-organization &
management facilitated by
information radiators

190
 Information Radiator Examples
Information radiators communicate what’s important for your
project; each team has unique needs. Some examples:
• Project Charter • Information architecture diagrams
• Agile Manifesto • Burn Down Chart
• Key Contact Information • Other metrics
• Project Calendar (vacations, etc.) • Project Backlog and Timeline
• Objectives, Outputs & Outcomes • Current Iteration Story Cards & Tasks (Tasks,
WIP, To Verify, Done)
• Success Sliders
• Risks & Issues Log
• Scope & Objectives Chart
• External dependencies/groups
• Values/Rules of Engagement
• Days left in Sprint/Iteration
• Team Norms
• Various team personalization stuff
• System architecture diagrams

191
Team Room Examples

1. Portable easel
2. Smart board
3. Risks & Issues noted
4. Magnetic whiteboard
5. Plant needs water
6. Task board
7. Pair programming station
8. Status tracking by color
9. Nice chairs

192
 Communications Bandwidth
Agile workspaces & information radiators are
designed to reduce miscommunications, assumptions and
disconnects by maximizing communications bandwidth.

Face-to-face
Video &
Teleconferencing
Phone &
Instant Messaging

Email &
Portals

Documents

Unidirectional Activities Bidirectional Activities

193
 Distributed Daily Scrum Models
New York Mumbai

Isolated Scrum Teams

Independent Daily Scrums.
Daily Scrum Daily Scrum

Distributed Scrum of Scrums

Regular Scrum of Scrums.
Scrum of
Daily Scrum Scrums Daily Scrum

Integrated Scrum Team

Team members split across locations. Daily
Scrum

194
 Suggestions for Distributed Teams
• Ensure more frequent feedback with shorter iterations
• Use continuous integration, or at least regular builds
• Send ambassadors, maintain site liaisons
• Put phone/video/messaging communications technology to use
• Use wikis for common project info
• Use test scripts to understand requirements
• Separate teams by functionality, not technical specialty
• Expect more documents

Check out Martin Fowler’s article http://martinfowler.com/articles/agileOffshore.html#

UseContinuousIntegrationToAvoidIntegrationHeadaches

195
 Team Review
1. The ideal agile team size is ___________ a) nine
to ___________ people.
2. Agile teams embrace the concept of b) full
___________ instead of specialization.
3. Sharing functional responsibilities may c) utilization
require changes in ___________ policies
and compensation.
d) human resource
4. Most of the team members should be e) five
___________ time members of the
team. f) shared
5. A focus on ___________ typically results responsibility
in staff members working across teams
and projects, which greatly reduces
productivity.

1(e) (a) 2(f) 3(d) 4(b) 5(c)

196
The Scrum Process
Initial Planning*
Product Backlog
Release Planning
Sprint Planning
Sprint Backlog
Sprint
Sprint Review
Daily Scrum
Sprint Retrospective
Initial Planning
 Initial Planning at a Glance
Description
Series of facilitated sessions to Initial
orient team members to the Planning
project’s business value and
analytical background, the
Agile process, and one another.

Duration
As long as it takes!

Attendees Outputs
Team, Product Owner, •Project Orientation
ScrumMaster, SMEs •Process Orientation
•Team Orientation

199
 Comprehensive Sprint 0
Sample Sprint 0 Session(s) might include:

Agile Process Training Process Discovery

Product Discovery o Process Value Stream Map
o Agile Games with Customers
o Key Metrics
o Collaborative Modeling Workshop
o User Story Creation and Estimation
o Product Backlog Prioritization Team Discovery
o System Design o Team Norms & Core Hours
o Architecture Spike o Iteration Structure
o “Ready” Definition
Project Discovery o “Done” Definition
o Sponsor Vision o Business value prioritization scheme
o Business Context, Key Metrics
o Team Structure (Core/Extended)
o Release Planning
o Stakeholder/Project Interactions
o Sprint One Planning

200
 Sprint 0 Review
1. Sprint 0 ___________ explicitly part of the scrum
framework. a) goals
2. The product owner, ScrumMaster, key sponsors, key b) is not
stakeholders, the ___________ and select subject
matter experts participate(s) in the discovery c) objectively
sessions.
d) process
3. Business stakeholders and sponsors provide a clearly
articulated vision with cascading ___________ so e) whole team
that we can ___________ measure future success.
f) constrain
4. In addition to providing context for the product,
discovery provides context around the project, g) specific
___________ and team .
5. We avoid BDUF design. Instead we define just
enough today to maximize the chance that we can
deliver value tomorrow, recognizing that if we get
too ___________, too early, we will likely over
___________ the team and get a less valuable
product. 1(b) 2(e) 3(a) (c) 4(d) 5(g) (f)

201
Product Backlog
 Product Backlog at a Glance
Description
List of desired functionality for Product
project prioritized by business Backlog
value by Product Owner.

Key Characteristics
• Contains requirements as
“User Stories”
• Near-term stories better
defined

Contains
Managed by • Prioritized Product Backlog Items or User Stories
Product Owner, ScrumMaster • Rough estimates
• [Optionally] Forecasted iteration boundaries
• [Usually] Release Dates

203
 Product Backlog Essentials
Adding User Stories
• Anyone can suggest new User Stories High priority items
• Product Owner prioritizes them are better defined

Estimating & Elaborating

# Backlog Item Estimate
• High-priority items are estimated and
described most precisely, since they will be 1 Create login screen .5
worked on first …
• Low-priority items are generally estimated 20 Allow user to browse 8
and described coarsely recently viewed items
…

Prioritizing 60 Add personalization 30 (or so)

• Prioritization is based primarily on Business

Value
Low priority items are
often “epics”

204
 Backlog Prioritization: A Closer Look
While business value should be the primary Product
Backlog prioritization criterion in most cases, it isn’t
the only one to consider. One might also factor in:
o Risk
o Complexity
o Demand
o Integration points from/to related projects or vendors

Some Tips:
 Create a prioritization scheme and Release Schedule that maximize the benefit realized
from incremental releases.
 Ensure that business needs and technical ones are balanced openly and jointly.

205
 Product Backlog Review
1. The product backlog is essentially a a) epic or feature
___________ to-do list.
2. A generic term for an item in the product
b) never-ending
backlog is ___________, a.k.a. PBI. c) many
3. A PBI can be expressed in ___________ or d) more detail
other concise formats.
e) product backlog
4. A PBI can be expressed in user story format
even if it will take ___________ sprints to item
complete
f) user story
5. PBIs can be at varying levels of detail, from an
___________ that can take several releases to
finish, all the way down to a user story which
can be completed in a single sprint.
6. High priority items are defined in ___________
than are lower priority items.
1(b) 2(e) 3(f) 4(c) 5(a) 6(d)

206
Release Planning
 Release Planning at a Glance
Description
Initial project planning session, Release
to review initial Product Backlog Planning
and define Releases.

Duration
2-4 hours

Attendees
Team, Product Owner,
ScrumMaster Outputs
• Release Plan
• Refined Product Backlog

208
 Release Planning Sample Agenda
• Present Business Case & Desired Features
Product Owner describes vision for product and initial set of User Stories
• Estimate User Stories
Team estimates high-level features in terms of story points or ideal delivery days
• Prioritize User Stories
Product Owner assigns priorities based on business value
• Formulate Release Schedule
Group User Stories into “minimum marketable feature sets,” set Release dates

Some Tips:
 This meeting should revolve primarily around the Release Schedule
 Product Owners: Come prepared with an initially prioritized Product Backlog
 Team: Come prepared with initial estimates for Product Backlog items

209
 Planning Releases with Story Maps
• Choose coherent
groups of
features that
consider the span R1 S1 R1 S2 Time R2 S1 R2 S2
of business
functionality and Access Provide Filter Sort
user activities Record Nurse ID Records Records

• Support all
necessary
Priority
Provide Search
activities with the Patient ID Records
first release
• Improve activity Review View Add Search
support with Record History Comment History
subsequent
releases Update Enter Notify of Reference
Record Updates Updates Validation

210
 Release Planning Review
1. The ___________ brings ___________ a) clearly
product backlog items to the release
planning session.
articulated
2. The ___________ provide(s) estimates in b) story points
___________ for the user stories and c) sprint
other product backlog items.
d) product owner
3. Based on story point estimates and
velocity projections, the product owner e) whole team
can segment out which user stories will go f) release
into which ___________, and, for high
priority, near term product backlog items,
even which ___________.

1(d) (a) 2(e) (b) 3(f) (c)

211
 Information Radiators - VMS
What are some Visual Management Systems?
• Outside of work, describe some visual control systems.
• Are there opportunities to use them
at home or work?

212
 1-Jun
3-Jun
5-Jun
7-Jun
9-Jun
11-Jun
13-Jun
15-Jun
17-Jun
19-Jun
21-Jun
23-Jun
Burnups,

25-Jun
Burndowns…
Cumulative Flow,

27-Jun
29-Jun
are only the beginning
Information Radiators

213
 Burndowns to Provide Context
Burndowns can provide context Product Owner Speaking
to make tough decisions at both To date, we have completed
feature 1 through feature 4.
the sprint and release level Unfortunately, we lost several
key members of our team
during iteration 6 and we are
unlikely to get all planned
Backlog features done for this
Feature 1 release, unless we execute
Feature 2 with perfection, which is
Feature 3 unlikely.
To Date Feature 4 We will likely delay feature 9
Feature 5 and 10 until the next release,
Feature 6 unless we make some
Feature 7 tradeoffs.
Feature 8
We already started
Feature 9
discussions with sales and
Feature 10
marketing and we may limit
our work on feature 5 and 6 in
the next Sprint.

214
 Burndown Review
1. Release level burn downs track story points a) burnup
remaining for a release. Sprint burn downs
have historically tracked ___________ b) cumulative flow
remaining on ___________. Some teams diagram
today now burn down ___________ instead.
c) hours
2. The primary purpose of the burndown is to
help teams face reality so that they can d) story points
make ___________. e) tasks
3. Variations on a burn down can be used, such f) tradeoffs
as ___________ or a ___________.

1(c) (e) (d) 2(f) 3(b) (a)

215
Sprint Planning
 Sprint Planning at a Glance
Description
Meeting to elaborate, estimate Sprint
and prioritize highest-value User Planning
Stories, creating Sprint Backlog.

Duration
2-4 hours

Attendees
Team, Product Owner,
ScrumMaster, SMEs Outputs
• Estimated & Prioritized User Stories
• Acceptance Criteria for User Stories
• Sprint Backlog with Tasks

217
 Sprint Planning Essentials
• Product Owners should arrive prepared to discuss top
priority stories and ask any questions regarding
alternate development paths
• The Team may prepare estimates and questions about
different development scenarios
• Acceptance criteria should be jointly discussed and
clarified
• The length of the Sprint Planning session will
generally be proportional to the length of the Sprint

218
 Sprint Planning Review
1. The ScrumMaster should create a ___________ of events,
holidays and team member schedules to support capacity a) trends
planning and coordination

2. The ScrumMaster should evaluate velocity data to spot

b) target
___________.
c) volunteer
3. At the beginning of sprint planning, team member availability
for the sprint is confirmed. This information is combined with d) calendar
the historical velocity data to determine ___________
velocity for the sprint. e) high priority
4. Team members ___________ for stories and tasks.
___________ are discussed to the extent necessary to allow f) team
the team to credibly commit to their completion within the
sprint. g) tasks
5. Some teams detail out all ___________ at Sprint Planning,
others detail out just ___________ tasks, others create just a h) user stories
few chunky tasks, and some team don’t detail out tasks at all.
6. The ___________ determines which user stories it will
commit to completing within the sprint. 1(d) 2(a) 3(b) 4(c) (h) 5(g) (e) 6(f)

219
Sprint Backlog
 Sprint Backlog at a Glance

Description
Sprint
List of desired functionality for
Backlog
development in the current
Sprint.

Key Characteristics
• Contains User Stories
estimated at task level
• Acceptance tests defined

Managed by Contains
Team, ScrumMaster • Prioritized User Stories & their tasks
• Task-level estimates
• Information needed to understand the tasks

221
Physical Task Boards

222
 Sprint Backlog Review
1. ___________ user stories are selected a) high priority
from the product backlog for inclusion in
the ___________.
b) physical
2. The sprint backlog is essentially a
c) sprint
detailed, short term, ___________ d) sprint backlog
covering items for the ___________. e) tasks
3. The sprint backlog may be stored in an f) to do list
electronic tool, a ___________ board, or
both.
4. ___________ may, or may not, be stored
in the sprint backlog.
1(a) (d) 2(f) (c) 3(b) 4(e)

223
Sprint
 Sprint at a Glance
Description
When the work gets done!
Sprint
Duration
1-4 weeks

Key Characteristics
• Isolated from further change
• Requirements elaborated and
refined
• Work organized adaptively

Involves Outputs
• Potentially shippable functionality
Team, ScrumMaster, Product Owner,
• Other items, as prioritized by Product Owner
SMEs

225
 Self-Organized Work Patterns
Effective Agile teams organize their work so that it flows:
• Critical activities are never stalled by work on lower-priority activities (which
may or may not arise in a future Sprint)
• Decisions are made at the last responsible moment
• Hand-offs are minimized in favor of synchronized collaboration

Sprint 1 Sprint 2 Sprint 3

Business Analysis

User Experience

Architecture or Risk “Spikes”

Coding & Refactoring

Testing

226
 Dialogue – Teamwork
Do your teams work like Agile teams?
• Does collaboration happen often across roles?
• Are activities assigned explicitly, or pulled based upon skill and
capacity?
• Do you have critical person dependencies?
• Is communication between team members open and regular, or
formalized and occasional?

227
 Sprint Review
1. The length of the sprint is ___________. a) daily scrum
2. The sprint contains four ceremonies: b) decouple
___________, ___________, ___________
and ___________. c) fixed
3. Some teams ___________ their release and d) sprint planning
planning cycles. These teams often continue
to use a fixed sprint cycle to provide a
e) sprint
cadence for planning and retrospectives. retrospective
4. Backlog grooming (User Story maturity) for f) sprint review
future sprints happens ___________. g) during the
current sprint
1(c) 2(d) (a) (f) (e) 3(b) 4(g)

228
Daily Scrum
 Daily Scrum at a Glance
Description
Brief, tightly facilitated status and Daily
risk management meeting for Scrum
Team & Product Owner.

Duration
10-15 minutes

Attendees
Team, ScrumMaster, optionally
Product Owner and Interested Outputs
Stakeholders • Risks & Issues
• Informal meetings

230
 Three Questions in Three Minutes
Each participant answers 3 questions:
• Reference specific tasks (at the task board if possible)
• Record and Review Risks and Issues
• Team members should speak to one another; this is an
alignment tool, not an exercise to report to the boss

1 What did you get done yesterday?

2 What will you get done today?

3 What’s in your way?

231
 Daily Scrum Essentials
Parameters
• Daily
• 10-15 minutes
• Everyone stands
• Risks & issues noted
• Not for problem solving!
• Additional meet-ups
arranged, often
immediately following the
Daily Scrum
• Core team talks Quick Quiz:
Who maintains the team board?
• Extended team listens

232
 Daily Scrum – Quick Quiz

Core / Extended Team

 ScrumMaster/ Agile PM
 Product Owner
 CIO
 QA Manager
 Tester
 Business Analyst
 Developer

Quick Quiz
Who is allowed to talk at the Daily
Scrum (Stand-up)?

233
 Key Benefits of the Daily Scrum
Some key benefits of the Daily Scrum include:
• Shared language among team members
• Real-time reallocation of resources
• Focus on value-creating activities
• Clear, prioritized work plan
for each day
• Builds team identity and
emotional commitment

234
 Daily Scrum Review
1. The daily scrum is often called a daily
___________. a) 15
2. The ScrumMaster can help make the daily b) after
standup effective by providing ___________
about schedules, days left in sprint, release c) co-ordinate
date, etc., during the first 45 to 90 seconds.
d) context
3. The focus of the daily standup is to convey
information so that the team can e) each other
___________ their collaboration.
f) standup
4. The daily standup should last no longer than
___________ minutes.
5. At the daily standup the team members talk
to ___________.
6. Detailed discussions and planning should
occur ___________ the daily scrum. 1(f) 2(d) 3(c) 4(a) 5(e) 6(b)

235
Sprint Review
 Sprint Review at a Glance
Description Sprint
Team demonstrates completed Review
functionality to interested
stakeholders, gathering
feedback.

Duration
2-4 hours

Attendees
Team, Product Owner, Outputs
ScrumMaster, optionally Users & • New Features on Product Backlog
• Reprioritized Product Backlog
Interested Stakeholders
• Revised Team or Project Structure

237
 Sprint Review
Present Completed User Stories
Demo live functionality completed in prior Sprint; no decks!

Record Customer & User Feedback

Adjust Product Backlog

o Remove completed functionality
o Reprioritize unfinished functionality
o Adjust priorities based on feedback

Adjust Project Structure

o Reformulate or resize the team
o Schedule or reschedule a release
o Decide to stop the project

238
 Sprint Demo Review
1. Another name for a sprint review is a sprint
___________ . a) context setting
2. The sprint review should start with b) demo
___________ including a discussion on overall
release progress, plans for the just completed c) sprint planning
sprint and identification of important tradeoffs
to discuss. d) working
3. The product owner and team members software
demonstrate ___________ built during the
sprint.
4. The sprint review is a forum for the team and
stakeholders to understand what has been
done, what is left to be done, and what is likely
to be done, so that they can make tradeoffs.
These tradeoffs will impact the upcoming
___________ meeting.
1(b) 2(a) 3(d) 4(c)

239
Sprint Retrospective
 Sprint Retrospective at a Glance
Description Sprint
Team continuous improvement Retrospective
session to reflect on project &
process issues and take action as
appropriate.

Duration
30 minutes – 1 hour

Attendees
Team, ScrumMaster, optionally Outputs
Product Owner • Process revisions
• Project or Team structure revisions
• Other improvement action items

241
 Sprint Retrospective Essentials
The useful way to do “Lessons Working Well Not Working Well
Automated unit 6am Daily Standup
Learned:” testing
• Periodically take a look at Customers highly Testing team
what is and is not working in satisfied availability
Retrospectives have Build cycle time
your process improved process
• Typically 15–30 minutes Estimates are Product Owner
stabilizing availability
• Done after every sprint Action Items
• Whole team participates Set SLA with QA PO delegates to
team proxy during Sprints
• Generates action items to
8am standup
continuously improve project
execution

242
Sprint Retrospective

243
 Sprint Retrospective Team Emotion
Too often, companies focus
too much attention on
metrics like Team
Performance and Team
Efficiency, while ignoring
metrics like Team
Emotion or Happiness

244
 Sprint Retrospective Review
1. The retrospective is often thought of as the a) anonymous
___________ part of the scrum process.
b) deltas
2. Effective retrospectives typically identify a
___________ of items to address. c) learnings
3. At a minimum, a retrospective should d) most important
identify ___________ and ___________.
e) pluses
4. Additional items to cover in a retrospective
can include appreciations and ___________.
f) small number
5. It is often helpful to collect ___________
feedback prior to the retrospective.

1(d) 2(f) 3(b) (e) 4(c) 5(a)

245
Thank You!
 Contact Us for Further Information

On the Web:
LeadingAgile.com
Facebook: /LeadingAgile
Twitter: @LeadingAgile

Posters with images from presentation

TheCriticalPath.info & Pictofigo.com

Last Updated: 2/27/2015

247
 Logistics & Expectations
Once this course has been completed:
• If you currently have a PMI credential (PMP or CAPM), you can
submit 21 PDUs directly to PMI
• If you are pursuing the PMI-ACP and are applying for 21 Agile
Contact Hours, you can submit this class under Agile Education
• If this is a public class, LeadingAgile will send you an email
within 24 hours with a link to a PDF version of this deck
• LeadingAgile will send you a letter of completion within two
business days

248
Hope is not a strategy
Luck is not a factor
Fear is not an option
• At LeadingAgile, we are dedicated to solving the challenges associated with
Agile in larger, more complex enterprises.
• We provide Agile training and coaching, strategic enterprise Agile
transformation consulting, and Agile project and portfolio management
services.

Specialties
• Scrum, XP, AUP, RUP, Project Management, Program Management, Portfolio
Management, Agile Training, Agile Coaching, Agile Consulting, Agile
Transformation

249