PMI-ACP Training Deck

PMI-AgileCertifiedPractitioner
PMI-ACPPrepWorkshop
LeadingAgile Atlanta
2180 Satellite Blvd Suite 400
Duluth, Georgia 30097
(678) 935 -4664

Rick Austin– Enterprise Agile Coach
PMI-ACP: Support Team Lead
PMI Agile Community of Practice: Volunteer
About me…
experience applying agile to
small teams
large distributed teams
change management
Agile Project Management
Volunteer and Leader
Expert in Financial
Services Industry
Georgia State Grad
Agile Transition
Director, Program
Manager
Applications Development
Manager
Solutions
Director of Development
Information Technology
Director

3
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?
Introductions

4
Write your questions on
Sticky notes as they
occur to you & affix
them to our Learning
Backlog.
Learning Backlog
Backlog

5
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
Approach

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

8
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
What the PMI-ACP and Agile are Not
≠

9
Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve
PMI-ACP and Adoption Curve
The
chasm
PMPACP
We are here!

10
Knowledge & Skills (50% of exam)
Percentage of Knowledge and Skill Content / % of Exam
Level 1 (66% / 33%)
(18 knowledge/skills)
Level 2 (24% / 12%)
Level 3 (10% / 5%)
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
stakeholder values
Business case development Applying new Agile practices
Brainstorming techniques Colocation (geographic proximity)/distributed
teams
Compliance (organization)
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.,
prototyping, simulation, demonstrations,
evaluations)
Participatory decision models (e.g., input based,
shared collaboration, command)
Innovation games
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

11
Tools & Techniques (50% of exam)
Communications
• information radiator, team space,
agile tooling, osmotic
communications for colocated and/or
distributed teams, daily stand-ups
Planning, monitoring, and
adapting
• retrospectives, task/Kanban boards,
timeboxing, iteration and release
planning, WIP limits, burn down/up
charts, cumulative flow diagrams,
process tailoring
Agile estimation
• relative sizing/story points, wide band
Delphi/planning poker, affinity
estimating, ideal time
Agile analysis and design
• product roadmap, user
stories/backlog, story maps,
progressive elaboration, wireframes,
chartering, personas, agile modeling
Product quality
• frequent verification and validation,
test-driven development/test first
development, acceptance test-driven
development, definition of done,
continuous integration
Soft skills negotiation
• emotional intelligence, collaboration,
adaptive leadership, negotiation,
conflict resolution, servant leadership
Value-based prioritization
• return on investment (ROI)/net
present value (NPV)/internal rate of
return (IRR), compliance, customer-
valued prioritization, minimally
marketable feature (MMF), relative
prioritization/ranking
Risk management Metrics
• risk- adjusted backlog, risk burn down
graphs, risk-based spike Metrics
Including but not limited to: velocity,
cycle time, earned value management
(EVM) for agile projects, escaped
defects
Value stream analysis
• value stream mapping

13
Community Guide of the PMI-ACP
Source: PMI.org/Agile

16
• 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.
Agile Manifesto

17
Agile is Not New
1943
1950-
1960s
1985
1990
1995
1996
1997
1998
2000
2001
USAF & NASA
X-15 hypersonic jet
Iterative
Incremental Delivery
Hirotaka Takeuchi
& Ikujiro Nonaka
The New New
Product
Development Game
1990 - Sutherland &
Schwaber
Scrum Framework
DSDN Consortium
Dynamic System
Development
Method
1996 - Beck,
Cunningham, Jeffries
Extreme
Programming
Jeff de Luca
Feature Driven
Development
Alistair Cockburn
Crystal Methodologies
Robert Charette
Lean Development
Agile Manifesto
Taiichi Ohno
Toyota Production
System
Kanban
Hardware Software

18
Agile Practices
Lean
Kanban
PMBOK
Agile is an umbrella term for a group of iterative and
incremental software development methods.

19
Agile Tools
Process Tools
VersionOne
Rally Software
JIRA + GreenHopper
Team Foundation Server
Excel
Kanban
AgileZen
LeanKit Kanban
Kanbanery
Engineering Tools
Continuous Integration
http://jenkins-ci.org/
http://hudson-ci.org/
http://cruisecontrol.sourceforge.net/
Engineering Tools
Ruby
Cucumber for
ATDD/BDD: http://cukes.info/
RSpec: http://rspec.info/
Java
http://www.junit.org/
http://www.jmock.org/
.Net
http://www.nunit.org/
BDD for .NET: http://www.specflow.org/
http://www.nmock.org/

20
Agile Manifesto Values
Individuals & interactions Processes & toolsover
Working software
Comprehensive
documentation
over
Customer collaboration Contract negotiationover
Responding to change Following a planover
That is, while there is value in the items on the right,
we value the items on the left more.
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Source: www.agilemanifesto.org

21
Agile Manifesto Principles
Satisfy the
Customer
Welcome
Change
Deliver
Frequently
Collaborate
Daily
Support & Trust
Motivated
Teams
Promote
Face-to-Face
Conversations
Deliver Working
Software
Promote
Sustainable
Pace
Promote
Technical
Excellence
Maximize
Through
Simplicity
Have
Self-Organized
Teams
Reflect & Adjust
Regularly
Source: www.agilemanifesto.org

28
Flipping the Iron Triangle
Features Cost Date
Cost Date Features
Source: DSDM
Plan-
Driven
Value-
Driven
$

29
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.
Reducing the Cost of Change
Source: Examining the Cost of the Agile Change Curve by Scott Ambler

30
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

31
Deploy
Document
$
Incremental Value Delivery
Agile Concurrent Development
• Fund incrementally – opt to extend,
redirect or cancel at a very granular level
• Deliver & realize value steadily
• Validate designs with users & customers
• Continuously adapt to risk and change
• Integrate early & often
Waterfall Serial Development
Invest up front, only realize value at end, assuming value proposition hasn’t changed
Test
Code
Design
Analyze
$$$
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
$ $$

32
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.

33
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
Agile is Discipline w/o Undue Burden

34
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
Exercise – Batch vs Flow Throughput

35
Key Agile Principles Traditional Waterfall
Focus on Highest Value First
Align project, product and team visions by prioritizing by business needs, and
using well architected code, to deliver better quality products faster and
cheaper.
All or nothing
Tight coupling & bias toward building out internals in a breadth first
fashion means that nothing can be delivered in isolation, even if it’s
valuable.
Responding to Change
Acknowledge uncertainty & adapt to both external (market) and internal
changes, by modifying plans & approach. Use engineering principles to make
code base easy to modify.
Baseline & Change Control
Constrain or even completely eliminate any significant change other
than dropping features. Work to initial plans, even when they are
proven to be invalid.
Iterative
Use short time boxes to provide a rhythm, continually flow of value to the
customer, and refine deliverables over time.
Phased
No rhythm as project is executed using long phases.
Feedback & Continuous Improvement
Use continual feedback to inform plans and modify approach.
Lessons Learned at the End
Feedback is rarely given in time for it to be applied towards improving
processes and project execution.
Small, Integrated Teams
A small team size, and overlap in skills sets, simplifies communications, allows
everyone to see the big picture, creates self discipline and provides flexibility.
Silo Teams with Handoffs
Staff works in functional oriented groups, throwing documentation
and code over the wall.
Technical Excellence / Bake Quality In
Use TDD , ATDD, refactoring, and other strong engineering principles to
ensure quality.
Inspection
Attempt to ensure quality by after the fact inspection.
Agile Principles Compared

36
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.

37
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.
Agile Uses Rolling Wave Planning
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

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

39
• Top level goal(s) must be
communicated to all levels
of the organization
• Members of the
organization offer candid
information up the
management ladder.
• Leaders/Managers offer
guidance
(why and what ≠ how)
Principle - Self-Organized and Empowered
info
guide
info
guide
info
guideinfo
guide

40
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
Planning Game Agile planning meetings
Product Owner Customer Business representative to project
Retrospective Reflection “Lessons learned”-style meeting
ScrumMaster Coach Agile project manager
Development
Team
Team Empowered Cross-Functional team
Daily Scrum Daily Standup Brief daily status meeting

41
Some More Agile Terminology
Term Definition
Spike
Something cannot be estimated until a development team runs
a timeboxed investigation. The spike itself is a throw-away.
Can include risk, architectural, or any unknown.
Tracer Bullet
An experimental solution that cuts through all the "layers" of
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/

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

43
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
How does Agile Work?

44
Deploy
Document
$
Incremental Value Delivery
Agile Concurrent Development
• Fund incrementally – opt to extend,
redirect or cancel at a very granular level
• Deliver & realize value steadily
• Validate designs with users & customers
• Continuously adapt to risk and change
• Integrate early & often
Waterfall Serial Development
Invest up front, only realize value at end, assuming value proposition hasn’t changed
Test
Code
Design
Analyze
$$$
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
$ $$

45
Incremental and Iterative Delivery
Incrementing is more about delivery.
1 2 3 4 5
1 2 3 4 5
Iterating allows you to move from vague idea to
realization. Going from rough to polished
Image Credit: Jeff Patton

46
• 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).
Iterations

AgileMethods
Lean
Kanban
Extreme Programming
Scrum

48
“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.“
What is Lean?
Source: Wikipedia

49
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
Production System
What is Kanban?
Kanban is a scheduling system that tells
you what to produce, when to
produce it, and how much to produce.

50
• 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.
What is Extreme Programming?

51
Scrum is an iterative and incremental project delivery framework.
What is “Scrum?”
Source: Wikipedia

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

53
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
Agile Project Charter

55
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

56
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
7 Principles of Lean
Source: Mary and Tom Poppendieck

67
Process Cycle Efficiency is the key measure of Leanness
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.
Lean Process Cycle Efficiency
PCE = (sum of time for Value Added process steps)
(sum of time for All process steps)

70
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
Continuous Improvement
改善

74
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
Kanban – High Level
New
Candidates PO Approved Decomposed
Acceptance
Criteria
Testable
Example
Dev Review Ready for
Sprint
10 cards 6 cards 4 cards 4 cards 4 cards 8 cards 12 cards

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

76
Everything at once
=
many started
few finished
Costs of Over-Utilization
Develop Test
In Process Ready In Process Ready
4 slots 3 slots 4 slots 3 slots
WIP Limits = Fast
“A system of local optimums is not an
optimum system at all” - Eli Goldratt

78
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.
Agile Engineering Practices
Source: Bill Wake, http://www.xp123.com

79
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.
XP Roles - Coach

80
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.
XP Roles - Customer

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

82
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.
XP Roles - Tester

83
1. ______ is responsible for implementing the
code to support the user stories.
2. ______ help the customer define and
implement acceptance tests for user stories
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.
XP Roles – Quick Quiz
a) XP Coach
b) XP Customer
c) XP Programmer
d) XP Tester
1(c)2(d)3(a)4(b)

86
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
Simple Design and Refactoring

94
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.
Risk Burndown
As with a regular release burndown chart,
we should see a linear drop in risk over the
course of the project.
Plot your project risk exposure and
display it with other big visible charts
in your team area.
Source: Managing Risk on Agile Projects | Mike Cohn - Mountain Goat Software

95
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
then create Risk Register
Team identifies risks in all meetings and
add to information radiators
Conduct qualitative and quantitative
analysis. Determine how to respond
Facilitate the team in a qualitative
analysis, determine how to respond,
post results
Periodically review Risk Register and
make updates as needed
Constantly review risk and responses as
part of all meetings, reviews and
retrospectives
Source: Sliger & Broderick (2008),The Software Project Manager's Bridge to Agility, Addison-Wesley

96
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
Implicit Risk Management

97
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
Explicit Risk Management
Agile Risks, Agile Rewards, Smith and Pichler, Dr. Dobb’s 2005

99
User Interface Layer
Business Logic Layer
Persistence Layer
Work in Agile projects is organized by Units of Value, rather than
by Architectural Layer.
Work Organized by Value
Feature / User Story 2Feature / User Story 1 Feature / User Story 3

100
Key Characteristics
• High-level descriptions of desired
functionality and goals
• Implement “vertical slices” of the
system’s functionality
• “Contracts for conversation,” not
all-inclusive requirements
• User stories wait in the Product
Backlog until pulled into the Sprint
Backlog
• Contain Acceptance Criteria to
define “Done”
User Stories at a Glance
As a user I can create an account.
Estimate 21 Points
Priority 1 (High)
As a user I can enter a user
name.
Estimate 4 points
Priority 1 (High)
As a user I can enter
password.
Estimate 8 points
Priority 1 (High)
Product Backlog User Story
Sprint Backlog
User Stories

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

102
As a <type of user>,
I can <immediate goal>
so that <business outcome>.
User Story Template
User Role (Who?)
Desired Function (What?)
End Result (Why?)
Who, What, Why…
what’s not here?

103
Acceptance Criteria help to set scope and define what
Done means for a given User Story.
User Story Acceptance Criteria
• 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.
As a user, I can cancel a reservation.

104
Circle which attributes
make a good story and
then discuss as the group
What Makes a Good Story?
Independent
Valuable
Testable
CreativeEstimatable
Small
Negotiable
Source: Bill Wake

105
Pre Release Life of a User Story
• Phone # in US format, contains no
alpha characters, minimum 10 digits
• First name, Last name and email
address required
• Email specified in standard format
• Etc.
Acceptance Criteria Created
Prior to Release Planning
As a user
I want to create an account
User Stories Created Prior to
Release Planning
Sprint Tasks Created
at Sprint Planning
• Design UI Mock Up
• Write online help text
• Develop CSS/HTML
• Develop validation criteria
• Create database tables
• Code test fixtures
• Code
• Perform testing
Name Phone Email Valid
John Smith 215-555-1212 jsmith@ls.com TRUE
Smith 215-555-1212 jsmith@ls.com FALSE
John 215-555-1212 jsmith@ls.com FALSE
215-555-1212 jsmith@ls.com FALSE
John Smith jsmith@ls.com FALSE
Smith jsmith@ls.com FALSE
John jsmith@ls.com FALSE
Testable Examples (ATDD) Created Prior
to Sprint Planning
Estimate 5-Points
Priority 1 -High
(Created at Release Planning)

106
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.
Beyond User Stories

107
Low-fidelity prototyping is a
fast, cheap, easily iterated,
collaborative way to test various
concepts & approaches.
Low-Fidelity Prototyping in Agile
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

108
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
High-Fidelity Prototyping in Agile
Source: iRise Studio, www.irise.com

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

110
5. A ___________ defines how the software will
be implemented; it can define the external
behavior, ___________ design, or both.
6. As defined in this training, a specification builds
on a requirement with additional context,
conversations and ___________.
7. A specification should be ___________,
defining just enough to help the team build
confidently within the sprint.
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.
Agile Requirements
g) complexity
h) designs
i) internal
j) lightweight
k) specification
l) vary
5(k)(i)6(h)7(j)8(l)(g)

112
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
Agile Estimation Levels, Units and Sequences
Traditional project estimation
approaches may be necessary
for initial scoping, but should
rapidly be replaced by
empirical observation of Team
output capacity (velocity).
Avoid false precision to avoid
false expectations.

113
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.
Agile Estimation Essentials

114
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
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
Affinity Estimating
Smaller Larger

115
• Clifford the Big Red Dog
• Marmaduke
• English Bulldog
• Chihuahua
• Pug
• Scooby-Doo
• Great Dane
Exercise – Relative Dog Sizing
Rules Point Estimating:
Team decides scale
Discuss criteria for complexity
Find the reference point
Estimate size for remaining items
Based on Mike Cohn’s dog points

116
“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!)
Agile Estimation – Planning poker

117
5
Planning Poker Example
55Bill (Dev)
52Ann (BA)
58Vijay (QA)
33Susan (Dev)
Round 2Round 1Estimator

119
Scrum – 50,000 Foot View
Release
Planning
Sprint
Planning
Sprint
Review
Sprint
Retrospective

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

121
• 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.
Artifacts of Scrum

122
Scrum Milestones
Product
Backlog
• ____________
• ____________
• ____________
• ____________
• ____________
F3 F6
Release 1
F1, F2, F3
Release 2
F1, F2, F3
F4, F5, F6
Initial
Planning
ReleasePlanning
ReleasePlanning
F1
F2
F2 F1 F4
F5F3
U
S
1
U
S
2
U
S
3
U
S
4
U
S
5
U
S
6
U
S
7
U
S
8
U
S
1
U
S
2
U
S
3
U
S
4
U
S
5
U
S
6
U
S
7
U
S
8
ReleasePlanning
Sprint
Backlog
• ______
• ______
Sprint
Backlog
• ______
• ______
Sprint
Backlog
• ______
• ______
Sprint
Backlog
• ______
• ______
Sprint
Backlog
• ______
• ______
Sprint
Backlog
• ______
• ______
SprintPlanning
SprintPlanning
SprintPlanning
SprintPlanning
SprintPlanning
SprintPlanning

123
Scrum Milestones
Features User Stories MMF

124
The Scrum Sprint Cycle
Sprint Planning
Elaboration, estimation and
prioritization of highest-value
User Stories.
Sprint Backlog
Allow a user to enter a
login & password.
Allow a user to enter
personal information.
Allow user to enter billing
information.
SprintExecution
Complete Sprint Backlog
Team works on highest-value functionality until it
meets jointly defined Acceptance Criteria.
Sprint Review
Team demonstrates completed functionality to
interested stakeholders, gathering feedback.
Retrospective
Team reflects on project & process and takes action
as appropriate.
Production Release (Optional)
Generally occurs when a useful group of related
functionality has been completed.
Daily Scrum (or Standup)
15-minute status and risk management meeting for
Team & Product Owner.

125
Use a cadence of recurring working sessions to synchronize and simplify planning
while providing continuity
Cadence & Synchronization
Instead of wasting time coordinating numerous meetings and dates…

126
Instead of cube farm, organized by function…
We collaborate via flexible roles and simple rules to
decentralize decision making and get work done.
Small Collaborative Teams
AfterBefore

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

128
Cards move left to right, downstream, if there is space.
Tracking Work in a Sprint
Sprint Backlog In Progress Completed
10 cards 6 cards
10 cards 6 cards
10 cards 6 cards
Cards move left to right,
assuming there is space, then…
From Sprint Backlog to In Progress,
if there is space, and…
From In Progress to
Completed.

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

130
4. At the end of each ___________
the team demonstrates
_____________ they do this at
the ___________.
5. The total story points estimates,
for those stories that were
completed in a sprint, are added
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.
Scrum Process Review
g) sprint
h)sprint review
i) sprint retrospective
j) velocity
k) working software
4(g)(k)(h)5(j)6(i)

133
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
Product Owner Responsibilities

134
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
An Army of One?
Product Owners represent
many constituents with a single voice.

135
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

136
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?
Reluctant Product Owner

137
Sprint
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…)
Defining “Ready”
Ready In Process Done

138
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
Definition of “Ready”

140
A Typical Agile Pipeline
Ideation
Market Trends
Prototypes
Focus Groups
User Experience
Basic Workflows
Vision
Business Outcomes
Release Timing and Goals
Product Architecture
Epics and Features
Maturation
User Story Decomposition
User Story Maturation
Acceptance Criteria
Test Cases
Dependencies
Story Mapping
Prioritization
Epic Estimation
Backlog Development
Execution
Sprint Planning
Task Estimation
Daily Standups
Software Development
Testing
Burndowns
Documentation
Product Demos
Retrospectives
Current Sprint~2 Sprints Ahead>4 Sprints Ahead
Marketing/Sales, Product
Management, Product
Owners, Architects
Product Owners,
Architects, Dev Leads, QA
Leads, UX/Analysts
Leads, UX/Analysts, Dev
Team Members

141
Vision
Goal / Outcome
Epic
Feature Feature
Story Story Story Story Story
Feature
Goal / Outcome
Epic
Feature Feature
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.
• The names may also vary, so
“User Story” or “Story” are
often used interchangeably.

142
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
Agile Estimation Basics
Velocity requires stability to be accurate.

143
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
Definition of “Done”

144
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
information.
5 Pts Complete
As an Account Representative, I can view a
Policy Holder’s information.
8 Pts Complete
As an Underwriter, I can approve or reject
applications.
5 Pts 1 Pts Remaining
Total Sprint Velocity 15 Pts
Velocity Calculation
* Pts = Story Points
Next Sprint,
15 Pts would be our
projected capacity.

145
Metrics fall into two general categories:
Business Value
o ROI, IRR, NPV
o % cycle time reduction
o Customer satisfaction (NPS)
Diagnostic
o Velocity
o Successful builds per iteration
o Defects across iterations
o Code coverage
Defining Key Metrics in Agile
Tips:
• Measure outcome, not output
• Measure only a few things
• Ensure commonly understood
operational definition and
measurement plan
• Target specific questions and
audiences

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

147
Based on the velocity chart below, in what iteration can the
business expect 33 more story points completed?
Estimating Dates with Velocity
Velocity stabilizes as
business & technical
domain knowledge
increase and teams
move from forming &
storming to
performing.

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

149
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.
Agile EVM instead of Velocity
1. If you know why you use EVM now, the same applies to AgileEVM
2. Use the iteration as the unit for basing calculations

150
• 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
Sprint Planning Sample Agenda

Identifying&Modeling
Users&Customers

152
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.
Applications of User Models

153
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.
Users vs. Customers

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

155
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.
One Step Further - Personas
“Extreme Character Personas will lead you to stories, you
would be likely to miss otherwise”
User Stories Applied by Mike Cohn

156
Here are some example personas
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

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

159
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
ScrumMaster Responsibilities

160
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?
What do you do?

161
 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.
Ethical Leadership
Source: Based on Domains of Ethical Theories from Leadership Theory and Practice

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

163
ScrumMaster Encourages:
• Forthrightness
• Blameless observations
• Failing & learning fast
ScrumMaster Discourages:
• Defensiveness
• CYA retrenching
• Fear of failure
Failure – End, or Means?

164
• 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
Typical ScrumMaster Activities
“A dead ScrumMaster is a useless ScrumMaster”
- Ken Schwaber

165
• Can a ScrumMaster also be a team member?
• Can a ScrumMaster also be a product owner?
• What potential issues might arise from these
scenarios?
Dialogue – Hats of the ScrumMaster

166
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?
Group Discussion – PM vs. SM

167
• 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
Facilitation Methods

168
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.
Consensus Workshop Method “Sailboat”
Based on Speedboat by Luke Hohmann of Innovation Games

169
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
Facilitating Group Decision Making

170
 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
Active Listening

171
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
SELF-AWARENESS
Knowing one's internal states,
preferences, resources, and
intuitions
EMPATHY
Awareness of others' feelings,
needs, and concerns.
MANAGING EMOTIONS
Managing one's internal states,
impulses, and resources.
SOCIAL SKILLS
Adeptness at inducing
desirable responses in others.
MOTIVATION
Emotional tendencies that
guide or facilitate reaching
goals.
Self
Awareness
Self-
Management
Social
Awareness
Relationship
Management
With Others
WhatISeeWhatIDo
With Me

172
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

173
• 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.
Negotiations
Source: PMI PMBOK® Guide 4th Edition Section G.8

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

176
Steps
1. Intro + Rules
2. 2 minute prep time
3. Get an estimate
4. Create velocity chart
5. 2 minute iteration
6. 1 minute improvement
& new estimate
7. Repeat 5 times
8. Retrospective
Collaboration Exercise
Rules:
1. Start point = End point (person)
2. Process the most work possible
3. Balls must have air time when
being passed
4. Balls may NOT be passed
directly to your neighbor on
the left or right
5. Balls must be touched by each
and every person
6. Balls cannot be processed as
one group (the bag/box)
7. Balls left on the floor at the end
of an iteration are waste and
will be subtracted from your
production totalThank you Scott Dunn, Boris Gloger

177
 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.
Exercise - What did we learn?

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

179
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?
Team of Specialists

180
• 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.
Common Team Dysfunctions
What are some other dysfunctions you’ve seen?

181
 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.
Team Motivation
 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.

182
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?
Dialogue – High Performance Teams

183
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.
Self Organization
Source: Wikipedia

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

185
Team Diversity
We want a broad model of
diversity based on style,
not just demographics
• Change Readiness
• Emotional Intelligence
• Risk Aversion
• Motivation
• Work Style
We want diversity as
expressed in outer rings
Values
Beliefs
Risk Aversion
Emotional Intelligence
Motivation
Change Readiness
Religion
Communications Style
Work Experience
Geographic Location
Family Status
Education and
Qualifications
Age
Gender
Race
Sexual Orientation
Ethnicity
Mental Abilities
Physical Abilities

186
The Team
• Works cross-functionally
(reduce handoffs !)
• Shares roles to get the work done
(i.e. generalizing specialist)
Roles of the Team
• 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

187
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
Self Organizing Principles

188
This is not a cross-functional team:
Teams are Cross-Functional
This is.
Coding Testing
Analysis Coding Testing
Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5
Coding
Analysis
Testing
Coding
Analysis
Testing
Coding
Analysis
Testing
Sprint 2Sprint 1 Sprint 3 Sprint 4 Sprint 5

189
• Common area for collaboration
o Open flow of information
• Caves for privacy
o Intense problem solving
o Creative solitude
o Private phone calls
o Research
o Rocking silently and weeping
Caves and Commons Layout
We all need a place to call home
Whiteboard Covered Wall
Burndown
Chart
Cubicles
Cubicles
Information
Radiator

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

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

192
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

193
Documents
Email &
Portals
Phone &
Instant Messaging
Video &
Teleconferencing
Face-to-face
Communications Bandwidth
Agile workspaces & information radiators are
designed to reduce miscommunications, assumptions and
disconnects by maximizing communications bandwidth.
Unidirectional Activities Bidirectional Activities

194
Isolated Scrum Teams
Independent Daily Scrums.
Distributed Scrum of Scrums
Regular Scrum of Scrums.
Integrated Scrum Team
Team members split across locations.
Distributed Daily Scrum Models
Daily ScrumDaily Scrum
New York Mumbai
Daily ScrumDaily Scrum
Daily
Scrum
Scrum of
Scrums

195
• 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
Suggestions for Distributed Teams

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

The Scrum Process
Initial Planning*
Product Backlog
Release Planning
Sprint Planning
Sprint Backlog
Sprint
Sprint Review
Daily Scrum
Sprint Retrospective

199
Description
Series of facilitated sessions to
orient team members to the
project’s business value and
analytical background, the
Agile process, and one another.
Duration
As long as it takes!
Attendees
Team, Product Owner,
ScrumMaster, SMEs
Initial Planning at a Glance
Outputs
•Project Orientation
•Process Orientation
•Team Orientation
Initial
Planning

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

201
1. Sprint 0 ___________ explicitly part of the scrum
framework.
2. The product owner, ScrumMaster, key sponsors, key
stakeholders, the ___________ and select subject
matter experts participate(s) in the discovery
sessions.
3. Business stakeholders and sponsors provide a clearly
articulated vision with cascading ___________ so
that we can ___________ measure future success.
4. In addition to providing context for the product,
discovery provides context around the project,
___________ 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.
Sprint 0 Review
a) goals
b) is not
c) objectively
d) process
e) whole team
f) constrain
g) specific
1(b)2(e)3(a)(c)4(d)5(g)(f)

203
Description
List of desired functionality for
project prioritized by business
value by Product Owner.
Key Characteristics
• Contains requirements as
“User Stories”
• Near-term stories better
defined
Managed by
Product Owner, ScrumMaster
Product Backlog at a Glance
Contains
• Prioritized Product Backlog Items or User Stories
• Rough estimates
• [Optionally] Forecasted iteration boundaries
• [Usually] Release Dates
Product
Backlog

204
Adding User Stories
• Anyone can suggest new User Stories
• Product Owner prioritizes them
Estimating & Elaborating
• High-priority items are estimated and
described most precisely, since they will be
worked on first
• Low-priority items are generally estimated
and described coarsely
Prioritizing
• Prioritization is based primarily on Business
Value
Product Backlog Essentials
# Backlog Item Estimate
1 Create login screen .5
…
20 Allow user to browse
recently viewed items
8
…
60 Add personalization 30 (or so)
High priority items
are better defined
Low priority items are
often “epics”

205
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
Backlog Prioritization: A Closer Look
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.

206
1. The product backlog is essentially a
___________ to-do list.
2. A generic term for an item in the product
backlog is ___________, a.k.a. PBI.
3. A PBI can be expressed in ___________ or
other concise formats.
4. A PBI can be expressed in user story format
even if it will take ___________ sprints to
complete
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.
Product Backlog Review
a) epic or feature
b) never-ending
c) many
d) more detail
e) product backlog
item
f) user story
1(b)2(e)3(f)4(c)5(a)6(d)

208
Description
Initial project planning session,
to review initial Product Backlog
and define Releases.
Duration
2-4 hours
Attendees
ScrumMaster
Release Planning at a Glance
Outputs
• Release Plan
• Refined Product Backlog
Release
Planning

209
• 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
Release Planning Sample Agenda
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

210
Planning Releases with Story Maps
Time
Priority
• Choose coherent
groups of
features that
consider the span
of business
functionality and
user activities
• Support all
necessary
activities with the
first release
• Improve activity
support with
subsequent
releases
R1 S1 R1 S2
Provide
Nurse ID
Provide
Patient ID
Filter
Records
Sort
Records
Search
Records
Add
Comment
View
History
Enter
Updates
Search
History
Reference
Validation
Notify of
Updates
R2 S1 R2 S2
Access
Record
Review
Record
Update
Record

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

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

213
Information Radiators
1-Jun
3-Jun
5-Jun
7-Jun
9-Jun
11-Jun
13-Jun
15-Jun
17-Jun
19-Jun
21-Jun
23-Jun
25-Jun
27-Jun
29-Jun
Cumulative Flow,
Burnups,
Burndowns…
are only the beginning

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

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

217
Description
Meeting to elaborate, estimate
and prioritize highest-value User
Stories, creating Sprint Backlog.
Duration
2-4 hours
Attendees
ScrumMaster, SMEs
Sprint Planning at a Glance
Outputs
• Estimated & Prioritized User Stories
• Acceptance Criteria for User Stories
• Sprint Backlog with Tasks
Sprint
Planning

218
• 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
Sprint Planning Essentials

219
1. The ScrumMaster should create a ___________ of events,
holidays and team member schedules to support capacity
planning and coordination
2. The ScrumMaster should evaluate velocity data to spot
___________.
3. At the beginning of sprint planning, team member availability
for the sprint is confirmed. This information is combined with
the historical velocity data to determine ___________
velocity for the sprint.
4. Team members ___________ for stories and tasks.
___________ are discussed to the extent necessary to allow
the team to credibly commit to their completion within the
sprint.
5. Some teams detail out all ___________ at Sprint Planning,
others detail out just ___________ tasks, others create just a
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.
Sprint Planning Review
a) trends
b) target
c) volunteer
d) calendar
e) high priority
f) team
g) tasks
h) user stories
1(d)2(a)3(b)4(c)(h)5(g)(e)6(f)

221
Description
List of desired functionality for
development in the current
Sprint.
Key Characteristics
• Contains User Stories
estimated at task level
• Acceptance tests defined
Managed by
Team, ScrumMaster
Sprint Backlog at a Glance
Contains
• Prioritized User Stories & their tasks
• Task-level estimates
• Information needed to understand the tasks
Sprint
Backlog

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

225
Description
When the work gets done!
Duration
1-4 weeks
Key Characteristics
• Isolated from further change
• Requirements elaborated and
refined
• Work organized adaptively
Involves
Team, ScrumMaster, Product Owner,
SMEs
Sprint at a Glance
Outputs
• Potentially shippable functionality
• Other items, as prioritized by Product Owner
Sprint

226
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
Self-Organized Work Patterns
Coding & Refactoring
Business Analysis
Testing
Sprint 1
User Experience
Architecture or Risk “Spikes”
Sprint 2 Sprint 3

227
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?
Dialogue – Teamwork

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

230
Description
Brief, tightly facilitated status and
risk management meeting for
Team & Product Owner.
Duration
10-15 minutes
Attendees
Team, ScrumMaster, optionally
Product Owner and Interested
Stakeholders
Daily Scrum at a Glance
Outputs
• Risks & Issues
• Informal meetings
Daily
Scrum

231
• 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
Three Questions in Three Minutes
What will you get done today?2
What did you get done yesterday?1
What’s in your way?3
Each participant answers 3 questions:

232
Quick Quiz:
Who maintains the team board?
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
• Extended team listens
Daily Scrum Essentials

233
Core / Extended Team
 ScrumMaster/ Agile PM
 Product Owner
 CIO
 QA Manager
 Tester
 Business Analyst
 Developer
Daily Scrum – Quick Quiz
Quick Quiz
Who is allowed to talk at the Daily
Scrum (Stand-up)?

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

235
1. The daily scrum is often called a daily
___________.
2. The ScrumMaster can help make the daily
standup effective by providing ___________
about schedules, days left in sprint, release
date, etc., during the first 45 to 90 seconds.
3. The focus of the daily standup is to convey
information so that the team can
___________ their collaboration.
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.
Daily Scrum Review
a) 15
b)after
c) co-ordinate
d)context
e) each other
f) standup
1(f)2(d)3(c)4(a)5(e)6(b)

237
Description
Team demonstrates completed
functionality to interested
stakeholders, gathering
feedback.
Duration
2-4 hours
Attendees
ScrumMaster, optionally Users &
Interested Stakeholders
Sprint Review at a Glance
Outputs
• New Features on Product Backlog
• Reprioritized Product Backlog
• Revised Team or Project Structure
Sprint
Review

238
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
Sprint Review

239
1. Another name for a sprint review is a sprint
___________ .
2. The sprint review should start with
___________ including a discussion on overall
release progress, plans for the just completed
sprint and identification of important tradeoffs
to discuss.
3. The product owner and team members
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.
Sprint Demo Review
a) context setting
b) demo
c) sprint planning
d) working
software
1(b)2(a)3(d)4(c)

241
Description
Team continuous improvement
session to reflect on project &
process issues and take action as
appropriate.
Duration
30 minutes – 1 hour
Attendees
Team, ScrumMaster, optionally
Product Owner
Sprint Retrospective at a Glance
Outputs
• Process revisions
• Project or Team structure revisions
• Other improvement action items
Sprint
Retrospective

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

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

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

247
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

248
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
Logistics & Expectations

249
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

PMI-ACP Training Deck

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a PMI-ACP Training Deck

Semelhante a PMI-ACP Training Deck (20)

Último

Último (20)

PMI-ACP Training Deck