PMI ACP Exam Prep

PMI-ACP Exam Preparation Course
Introduction
Aaron MacDaniel, PMP, CSM, MBA

Lead Instructor - BetterPM.com
An Innate Images, LLC Company 1
Course Overview
This course is designed to help you tailor the Agile framework to accommodate
the needs of different types of projects, and will appreciate various tools and
concepts used by the Agile practitioner.
At the conclusion of the course you have learned the foundation required for
taking the Project Management Institute’s PMI® Agile Certification Exam and
achieving the PMI-ACPSM (Agile Certified Practitioner) certification.
This course comprises seven learning modules and one exam review module.
Throughout the course, references are made to key information from the PMI
Agile® Certified Practitioner (PMI-ACPSM) Handbook.
© BetterPM.com 2
Course Content
Value-Driven
The content from this Delivery
course is tailored to
adhere to the six domains
of knowledge as detailed Continuous
Improvement
Stakeholder
Engagement
in the PMI Agile Certified
Practitioner (PMI-ACP)®
Examination Content
Knowledge
Outline. Domains
The various sources of Problem
Boosting
Team
content in this course are Detection and
Performance
Resolution
separate from PMI but Practices
are directly related to the

Adaptive
six knowledge domains. Planning
© BetterPM.com 3
Topics Covered in this Course
 About BetterPM.com
 A typical “Waterfall” Project Lifecycle
 Specifics regarding the PMI-ACP credentialing process
 Manifesto for Agile Software Development
 Agile – How is it Different?
 Overview of an Agile project lifecycle
 Benefits and limitations of an Agile process
 Leveraging the benefits of multiple disciplines
 Scrum
 Other Types of Agile
 Current Trends and the Lean Startup
 PMI and Agile Project Management
© BetterPM.com 4
Course Objectives
 By the end of the course, you should be able to:
• Confidently explain the differences between the Agile approach and a typical
“Waterfall” project approach
• Know the basic pros and cons of each method
• Understand the basics of the Scrum approach
• Be able to recite the 3-4-5 rule of Scrum: 3 Roles, 4 Artifacts, and 5 Ceremonies
• Know the differences between PMP®, PMI-ACP®, and Scrum Master® certifications
 Upon completion of this course, you are entitled to earn 21 PDUs.

• Immediately download your course certificate right to your device (as a picture in
your pictures folder)
• Email yourself the certificate for printing at home
• Register this course as 21 Category A (R.E.P Courses) PDUs. Go to your PMI.org
profile, and enter course #PMAgile-1. We are provider #3330, BetterPM.com,
Innate Images LLC
© BetterPM.com 5
Outline of Course Modules
Below is a description of all modules in the course.
 The PMI-ACPSM Exam
• Pre-requisites for the exam
• The application process
• Structure of the exam. Knowledge domains covered.
• Self Study recommendations
• Practice exam
 Module 1: Concepts of Agile
• Differences between the Agile approach and a typical “Waterfall” project approach
• Agile Manifesto values and principles
• Agile vs. Waterfall: Pros and cons, and coexisting disciplines.
• The Scrum approach
• Key aspects of the PMI-ACPSM Handbook
• Exam Overview: Eligibility and continuing certification requirements.
© BetterPM.com 6
 Module 2: Value-Driven Delivery
• Value based prioritization
• Value stream analysis
• Decomposition
• Prioritization
• Incremental Delivery
 Module 3: Stakeholder Engagement

• Communications Management
• Feedback techniques for product
• Assessing and incorporating community and stakeholder values
• Active listening
• Business case development
• Facilitation methods
• The definition of Done
© BetterPM.com 7
 Module 4: Boosting Team Performance Practices
• Building empowered teams
• Brainstorming techniques
• Information radiator
• Globalization, culture, and team diversity
• Adaptive leadership
 Module 5: Adaptive Planning

• User stories/user maps
• Retrospectives
• Burn down/burn up charts
• Cumulative flow diagrams
• Timeboxing
© BetterPM.com 8
 Module 6: Problem Detection and Resolution
• Problem-solving strategies, tools, and techniques
• Test-driven development
• Continuous integration
• Acceptance test-driven development
 Module 7: Continuous Improvement (Product, Process, People)

• Knowledge sharing
• Coaching and mentoring within teams
• Time, budget, and cost estimation
• Agile communication tools
• Emotional intelligence
© BetterPM.com 9
PMI-ACP Exam Preparation
An overview of The PMI-ACPSM Exam

Module Overview
Over the course of eight modules you’ll
learn from all required knowledge domains
covered on the PMI-ACP® exam.
This module is intended to summarize the

format of the exam and review the scope of
the knowledge that’s tested. In addition, this
course includes a bank of sample exam
questions to help you study.
On the following pages we will cover:
 Eligibility requirements for the certification
 The breakdown of knowledge domains tested and the concentration of each in
the exam.
 Helpful tips regarding the style and format of the exam.
© BetterPM.com 11
PMI Agile Certification Eligibility Requirements
Project Management Institute’s eligibility requirement for the certification are listed
below. This course is intended to assist you solely with the final step: the PMI-ACP ®
exam.
Requirement Description
General project • 2,000 hours working on project teams
experience • These hours must be earned within the last 5 years
• Active PMP® or PgMP® will satisfy this requirement.
Agile project • 1500 hours working on agile project teams or with agile
experience methodologies
• These hours are in addition to the 2,000 hours required in
“general project experience.”
• These hours must be earned within the last three years.
Training in agile • 21 contact hours. This course fulfills this requirement.
practices • Hours must be earned in agile practices
Examination • Tests knowledge of all agile fundamentals
PMI’s exam requirements are subject to change at any time. Refer to their online
listing to see the current requirements. (http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx)
© BetterPM.com 12
The Domains of Knowledge Tested
The exam consists of 120

multiple choice questions
with a three-hour time limit.
Twenty of the questions are

considered pretest questions
for future versions of the
exam and are not included in
your score – although they
are randomly placed
throughout the exam and you
will need to answer them like
any other question.
The exam is split evenly

between Tools & Techniques
and Knowledge & Skills.
© BetterPM.com 13
The Knowledge and Skill Levels
The three knowledge and skill levels are

weighted differently:
• Level one contains 33% of the

questions.
• Level two contains 12% of the
questions.
• Level three contains 5% of the
questions.
© BetterPM.com 14
Tools and Techniques Portion
The following slides summarize the topics covered in each knowledge domain as
listed in the PMI-ACP Examination Content Outline. This course was developed to
help you learn about the core concepts identified by the exam outline. The full
examination outline is available on PMI’s website.
http://www.pmi.org/en/Certification/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx
© BetterPM.com
Tools and Techniques Portion
The 60 questions comprising Tools and Techniques cover the following topics:
Tool Examples
Communications Information radiators, team space, agile tooling, osmotic
communications for colocated and/or distributed teams,
daily stand-ups.
Planning, monitoring Retrospectives, task/Kanban boards, time-boxing,
and adapting 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 Product roadmap, user stories/backlog, story maps,
design progressive elaboration, wireframes, chartering,
personas, agile modeling
Product quality Frequent verification and validation, test-driven
development, acceptance test-driven development,
definition of done, continuous integration
© BetterPM.com
Tools and Techniques Portion (cont’d)
The 60 questions comprising Tools and Techniques cover the following topics:
Tool Examples
Soft skills negotiation Emotional intelligence, collaboration, adaptive
leadership, negotiation, conflict resolution, servant
leadership
Value-based Return on Investment (ROI,) net present value (NPV,)
prioritization internal rate of return (IRR,) compliance, customer-
valued prioritization, minimally marketable feature
(MMF,) relative prioritization, ranking.
Risk management Risk-adjusted backlog, risk burn down graphs, risk-based
spike
Metrics Velocity, cycle time, earned value management (EVM) for
agile projects, escaped defects.
Value stream analysis Value stream mapping
© BetterPM.com
Knowledge and Skills Portion – Level 1
 Active Listening
 Agile Manifesto Values and Principles
 Assessing and incorporating community and stakeholder values
 Brainstorming techniques
 Building empowered teams
 Coaching and mentoring within teams
 Communications management
 Feedback techniques for product (e.g., prototyping, simulation,
demonstrations, evaluation)
 Incremental delivery
 Knowledge sharing
 Leadership tools and techniques
 Prioritization
© BetterPM.com
 Project and quality standards for Agile projects
 Stakeholder management
 Team motivation
 Time, budget and cost estimation
 Value-based decomposition and prioritization
© BetterPM.com
 Agile frameworks and terminology
 Building high-performance teams
 Business case development
 Colocation (geographic proximity)/distributed teams
 Continuous Improvement Processes
 Elements of a project charter for an agile project
 Facilitation methods
 Participatory Decision Models (e.g., input-based, shared collaboration,
command)
 PMI’s Code of Ethics and Professional Conduct
 Process Analysis Techniques
 Self assessment
 Value-based analysis
© BetterPM.com
 Agile contracting methods
 Agile project accounting principles
 Applying new agile practices
 Compliance (organization)
 Control limits for agile projects
 Failure modes and alternatives
 Globalization, culture, and team diversity
 Agile games
 Principles of systems thinking (e.g. complex adaptive, chaos)
 Regulatory compliance
 Variance and trend analysis
 Variations in agile methods and approaches
 Vendor management
© BetterPM.com
Module 1: Introduction to Agile

Module Overview
This module introduces the core aspects of the agile framework, and it is geared
to better prepare you for the in-depth modules (2-7) which will cover many of the
concepts in greater detail. At the conclusion of this module, you should have a
good understanding of the agile framework for software development.
Specifically In this module:
• The Waterfall Model as a contrast to Agile
• A History of Agile
▫ The Software Alliance
▫ The Agile Manifesto
▫ 12 principles of the Agile manifesto
▫ A history of the concept of “Chickens and Pigs”
• Comparisons between Waterfall and Agile
• Scrum
▫ A primer on scrum and how it relates to agile
▫ The product backlog
▫ The daily standup
© BetterPM.com 23
Module Overview (cont’d)
• Team Collaboration
▫ How the Chicken and Pig metaphor has evolved to expect everyone to have a stake in the
project.
• Scrum Components
▫ Sprints/Iterations
▫ User Stories
▫ Estimating User Stories
© BetterPM.com 24
Module Objectives
At the conclusion of this module, you should:
 Understand the key differences between the Waterfall model and the Agile framework.
 Be familiar with the core principles that have arisen out of the Agile Manifesto.
 Be aware of the variations of agile and know how scrum fits in as a part of agile.
 Understand the mechanics of the daily scrum and the working of the product backlog.
© BetterPM.com 25
Waterfall Model: Introduction, Pros and Cons
Throughout this course, in conversations among project managers & software

developers, and in current industry periodicals you will encounter a number of
opinions on the various options for managing your project teams.
In the past 15 years, the agile

framework has begun to serve as
a contrast to waterfall and a viable
option to managing any project.
The waterfall development model
Although agile arose from a need originates from the manufacturing
in the software industry, almost and construction industries, where
any project or process can benefit after-the-fact changes were
from the framework. detrimental to profits and delivery
So before we learn about agile, times.
it’s important to understand one
In the 1970s and 1980s it was
of the predecessors that agile
adapted for software development.
arose from.
© BetterPM.com 26
Waterfall Model: Introduction
What is Waterfall?
• Waterfall projects were in use in many industries – including software many years
before Agile came into formal existence. It’s a methodology in the Software
Development Lifecycle (SDLC) and other industries outside of software which
resists the revisiting and revising of any prior phase once it's complete.
• The waterfall model illustrates the development process in a linear sequential flow.
The idea being that ones you passed a stage in development you rarely came back
to revisit it or iterate (an operative word you’ll learn about with Agile.)
• Any phase in the development process begins only if the previous phase is
complete. It isn’t forbidden to go back a step if requirements have changed, but
it’s an expensive proposition that’s not easily accommodated by the discipline.
• The waterfall approach does not define the process to go back to the previous
phase to handle changes in requirements. As a result, different projects may follow
different approaches to handle such situations.
• The waterfall approach is the earliest approach that was used for software
development largely because it was the only one available at the time.. Initially,
most projects followed the waterfall approach because they did not focus on
changing requirements.
© BetterPM.com 27
A Typical “Waterfall” Project Lifecycle
Feasibility Why the name waterfall?
Because other than some

Requirement iterations in the build and
test phases, everything
flows downstream and
doesn’t return.
Design
Build
Test
Errors and Rework
Waterfall doesn’t prohibit going back “upstream” to fix

Deploy
problems, but the methodology isn’t well set up to support the
process, and as a result significant time and expense are
incurred.
© BetterPM.com 28
The Emergence of Agile
• By the 2000s, the concept of iterative development as a less rigid alternative
to waterfall began to take shape among many in the software development
community.
• The term “Agile” was first coined in 2001 by a group of 17 software
developers when meeting in Utah to discuss lightweight development models.
• Many of these developers formed the Agile Alliance to promote software
development according the visions of their charter, which they called the “Agile
Manifesto.
• The Agile Manifesto has become a key
foundational element in the guiding
principles of what has become known to be
simply, “Agile.”
• Strictly speaking, Agile is not a model,
discipline or a methodology. It’s a framework
that is still evolving.
© BetterPM.com
Agile Manifesto
Below is the wording of the Agile Manifesto that originated in the 2001 meeting
and is still used today. You can find the full text at this link:
http://www.agilealliance.org/the-alliance/the-agile-manifesto/
“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 and interactions over processes and tools

 Working software over comprehensive 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.”
© BetterPM.com
Agile Manifesto – 12 Principles
The Agile Manifesto is supplemented by 12 key principles, which are listed here:
1. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.
2. Welcome challenging requirements, even late in development.
Agile processes harness change for the customer’s competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference toward a shorter timescale.
4. Business people and developers must work together daily
throughout the project.
© BetterPM.com
Agile Manifesto – 12 Principles (cont’d)
5. Build projects around motivated individuals. Give them the

environment and support they need and trust them to get the
job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
© BetterPM.com
Agile Manifesto – 12 Principles (cont’d)
9. Continuous attention to technical excellence and good design

enhances agility.
10. Simplicity – the art of maximizing the amount of work not done
– is essential.
11. The best architectures, requirements and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Reference:
http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/
© BetterPM.com
Differences Between Waterfall and Agile
So which framework is right? There’s no right or wrong answer, and in many cases
companies practice both among departments and groups. Below is a summary of
some of the key differences between the two.
Waterfall Agile
Plan driven Learning driven
Infrequent team communication Continuous team communication
Deliver once, Big design up front, typically 9-12 Deliver smaller, business focused phases, usually
months 1-2 months
Development done by layers, presentation, Develop end-to-end functional slices
persistence, business, etc.
© BetterPM.com
Differences Between Waterfall and Agile
Waterfall Agile
Integration occurs at the completion of each Continuous integration (daily builds)
layer
Testing occurs at the end of the project, mostly Fully automated, continuous testing, unit level
functional testing and functional testing
High cost to change Low cost of change
Must nail down requirements up front Expects, accommodates, changes to

requirements
“Big Design Up Front” “Rough Design Up Front”
(also referred to as ‘Big Requirements up Front’)
© BetterPM.com
Agile Manifesto Tenets
As you prepare for the exam, keep in mind these key items favored by the
agile framework over the waterfall model.
Agile Waterfall
Individuals and Over Process and Tools
Interactions
Comprehensive
Working Software Over
Documentation
Customer
Over Contract Negotiation
Collaboration
Responding to
Over Following a Plan
Change
Strong, collaborative Individual Work
Over
teams Packages
© BetterPM.com
Agile Projects: Control Limits
The Agile framework is one of adaptation rather than prescribed or defined
process. However, the framework is not without controls. Some tools used are:
• Product Vision: A high-level summary of the desired outcome.
• Release Planning: Conducted at the beginning of a release as stories are taken on
by the team. A required agile activity.
• Iteration Planning: A list of prioritized features that is converted into work during
release planning. A required activity
• Daily Standup: Short meetings where team members review what they
accomplished, what is upcoming, and what issues they are facing.
▫ Also referred to as the “Daily Scrum”
We will cover each of these topics in greater detail throughout the course.
© BetterPM.com
Agile Practices and Management
When studying for the exam, know that Agile respects certain components of the
software development lifecycle (SDLC,) and its methodologies span both practices
(building software) and management (coordination activities.) Management of
complex agile projects is known as Scrum – which is introduced in detail later on
the next pages.
Agile Practices Agile Management
Extreme
Programming Scrum
(XP)
Examples of Pragmatic
Agile variations A Note on Terms
Programming
Scrum implies Agile, but
Agile does not imply Scrum.
Agile Modeling Scrum is an agile
management technique.
© BetterPM.com
Agile Isn’t Just for Software Anymore
Although the framework is relatively new in comparison to methodologies such as
Waterfall, and although the software industry has been the first to champion the use of
agile, the framework isn’t just for software development.
 An alternative to the concept of cost accounting in business today (which focuses on

cost cutting,) is the notion of Throughput Accounting. Proffered by Eliyahu Goldratt,
the goal is to improve profit performance with better management decisions by using
metrics that directly measure the effects of those decisions.
 Mark Addleson’s Beyond Management: Taking Charge at Work1 states,
“By looking for practices that are good for knowledge-work, which break the
stranglehold of management on how to organize work, we can learn a lot from a
mini-revolution in software development known as ‘agile methods.’… Agile methods
offer a way out of this impasse, with a far reaching, even radical solution to
building good software”
 Lonely Planet is using agile to have their team of in-house lawyers plan their work
load and ensure priority items are done on time. (Reference: Agile Today2, May 2011)
1: http://www.amazon.com/gp/product/0230308163/ref=as_li_ss_tl?ie=UTF8&tag=stevdenndotco-
20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0230308163
2: http://www.agileaustralia.com.au/AgileTODAY/Volume/2011/AgileTODAY-Vol-1-MAY-2011.pdf
© BetterPM.com
Agile Isn’t Just for Software Anymore
In the modules ahead, we’ll learn about the following tools and techniques that
are not directly tied to the software industry and can be used in various lines of
business to improve the quality and success of products.
All of these concepts that we’ll cover can be used in a variety of industries:
 Using Kanbans to determine what has to be done next.
 Timeboxing
 Asking “Who,” “What” and “Why” by documenting a user story
 Frequent user testing
 Shorter and more meetings with only the relevant people.
 Pairing together subject matter experts
 Setting priorities as a team
 Iterative development
© BetterPM.com
The Scrum Framework – an Introduction
In the next slides we will dive in to the Scrum framework. Scrum is an approach in
agile that is heavily used when dealing with complex projects. Although scrum is
not a necessary component of every agile project, it’s possible that you’ll be
performing the activities on the following slides and refer to them as part of an
“Agile Project,” not a “Scrum Project” or “Scrum Steps.”
Below are key steps in how the scrum framework operates.
 A product owner creates a prioritized wish list called a product backlog.
 During sprint planning, the team pulls a small chunk from the top of that wish
list, a sprint backlog, and decides how to implement those pieces.
 The team has a certain amount of time, a sprint, to complete its work - usually
two to four weeks - but meets each day to assess its progress (daily scrum.)
 Along the way, the Scrum Master keeps the team focused on its goal.
© BetterPM.com
The Scrum Framework – an Introduction
(cont’d)
 At the end of the sprint, the work should be potentially shippable, as in ready
to hand to a customer, put on a store shelf, or show to a stakeholder.
 The sprint ends with a sprint review and retrospective.
 As the next sprint begins, the team chooses another chunk of the product
backlog and begins working again.
On the next slide is a visual of the scrum framework, which is a central image in
the Agile Manifesto.
© BetterPM.com
Scrum Lifecycle
Daily Scrum
Meeting or Standup
Daily
Sprint, or “Iteration”
Sprint Backlog Backlog tasks 2-4 weeks

created
by team
[Potentially] Shippable
Product Backlog Product Increment
as prioritized by the Product Owner
These items are not necessarily the same relative size
© BetterPM.com
What is the Product Backlog?
A significant component to the previous image is the product backlog.
 The product backlog is a prioritized list of work (can consist of User Stories and Bugs) to
be performed on a product
 Product Owner responsible for prioritisation
 Anyone can contribute on backlog items
 Below is an example of a backlog as an “information radiator,” which is defined in a
later module.
Story To Do In Dev Test Complete

As a User, I… Code the Test the Test the Test the Test the Code the
8 points 8 points 5 points 8 points 5 points 5 points 9 points
As a User, I… Code the Test the Code the Test the Code the Code the
As a User, I… Code the Test the Code the Code the Test the Code the
As a User, I… Code the Test the

4 points 8 points 5 points
© BetterPM.com
Confused Yet? Agile, XP, Scrum, etc.
By now in this module (and before we go any further,) you should be familiar
with a number of new terms but are likely not yet able to keep them all straight.
The grid below helps you differentiate between the different terms each
methodology uses, with Agile and XP being most similar to each other.
Agile XP Scrum
Agile Product Product Manager Product Owner
Manager
Agile Facilitator Coach Scrum Master
Stories Stories Backlog Items
Iteration Iteration Sprint
Iteration Demo Iteration Demo Sprint Review
Iteration Planning Iteration Planning Sprint Planning
Release Planning Release Planning Product Backlog
Standup Meetings Standup Meetings Daily Scrum
© BetterPM.com
Scrum Team Characteristics
Below are the main characteristics of an agile (scrum) team. You will become very
familiar with these themes, as they are a central part of the agile framework and
are covered extensively on the exam.
 Self-organizing
 Cross-functional
 Seven plus or minus two people
 Responsible for committing to work
 Authority to do whatever is needed to meet commitment
The early days of scrum and agile used a metaphor of chickens and pigs to help
explain the roles. The following slides introduce the concept. As you review the
story, keep the above bullet points in mind.
© BetterPM.com
Scrum Teams: A History Chickens and Pigs
Prior to 2011, the Official Scrum Guide referred to certain team members
as Chickens and pigs. Below is a history:
 During the month-long sprints, the team holds daily meetings-- the
daily Scrum.
 Meetings are typically held in the same location and at the same time
each day - ideally in the morning, as they help set the context for the
coming day's work.
 Each participant in the Daily Scrum is known as either a chicken or a pig,

depending on his involvement in the project.
 From Agile Software Development with Scrum. Schwaber, Ken; Beedle, Mike
© BetterPM.com
Scrum Teams: A History Chickens and Pigs
And here is how the mythical conversation would go:
 Chicken: “Let's start a restaurant!”
 Pig: “What would we call it?”
 Chicken: “Ham n' Eggs!”
 Pig: “No thanks. I'd be committed, but you'd only be involved!”
© BetterPM.com
Chickens and Pigs: The Message
In other words: pigs sacrifice their lives for the project, whereas
chicken only have to give up their eggs.
Today’s Message: The concept of chickens and pigs may occasionally

be used, but keep in mind this core takeaway: All team members of
the project must own it as having skin in the game. In agile projects,
it’s expected that the team take an attitude of, “We’re in this
together.”
© BetterPM.com
Chickens and Pigs Today
 The Official Scrum Rulebook1 (October 2011) by Ken

Schwaber and Jeff Sutherland removes this reference.
 Chickens have evolved to be known as the customer unit
and pigs have evolved to be known as the development unit.
 Although the pejorative names are removed, the goals
remain the same – the team has shared responsibility and
must function with the same goals.
 The following slide visualizes the various roles of the team
1: http://www.scrum.org/Scrum-Guides
© BetterPM.com
Scrum Roles
Scrum
Team
Master
Members
Scrum Roles Product

Owner
Users
Stakeholders
© BetterPM.com
Scrum Team
The Team comprises a number of different subject matter experts and also
includes customer-facing roles. The customer unit is not necessarily as heavily
involved as the core development unit, yet all roles play a key part in the team.
Customer Unit Development Unit
People who are involved but not Members of Scrum Team are known
dedicated to the project are known as as Pigs because they are committed
Chickens - they may attend Scrum to delivering the Sprint Goal
meetings as observers  Developer
 Customer  Product Analyst
 Product Manager/ Product Owner  QA
 Marketing  IT
 Executives  Project Manager
 Client Services  Graphic Designer
 Technical Writer
© BetterPM.com
Scrum Team – Roles and Responsibilities
Product Owner Development Unit
 Product Vision & Roadmap  Estimate
 Manage product backlog  Plan and commit for the
• Ranks and prioritizes the backlog. iteration
 Set clear expectations for  Execute the iteration
acceptance
 Demo
 Provide necessary details at the
 Communicate
appropriate time for Development
Unit
 Communicate
© BetterPM.com
Other components of an Agile Project
On the following slides we’ll discuss a number of key components, concepts and
tools used by agile teams to succeed on their projects. The items are presented in
this module as an introduction to what will be covered in greater detail in the
subsequent modules.
Ahead in the next module:

 The Scrum Master and their responsibilities.
 User Stories and how to estimate them.
 The Sprint
 Burn-down charts
 The Daily Scrum (standup)
© BetterPM.com 54
Sprint Review
 Demo - during this meeting the team presents to management, customers,
users and the Product Owner the product increment that has been built during
the Sprint.
 Closeout - the Sprint is closed out. All work is marked complete.
 Retrospective - all good and bad things that happened during the Sprint are
documented and taken into consideration for the next Sprint.
 PowerPoint presentations are forbidden!
© BetterPM.com
Agile’s Variations and Derivatives
In the following slides we will review a number of agile’s derivatives in greater
detail. Not all of agile’s variations are covered here on in the exam, and not all of
them use every tool and technique presented in the previous section, but the key
concepts covered in the exam are discussed.
 In particular, we’ll cover Agile Modeling, Empirical Process Control, and

Velocity Tracking.
© BetterPM.com
Variations of Agile
In the short lifespan of the Agile name, a large number of variations have
emerged, each with their own rules and idiosyncrasies.
 Extreme Programming (XP) Note:
 Scrum Not all of these
variations are
 Agile Modeling covered in this
 Feature Driven Development (FDD) course, nor are they
covered in the exam.
 Open Unified Process (OpenUP)
 Rational Unified Process (RUP) For more information
about each variation,
 Agile Unified Process (AUP) click on the hyperlink
 Essential Unified Process (EUP) symbol
 Dynamic Systems Development Method (DSDM)
 Velocity Tracking
© BetterPM.com
Future Directions
Just as this course will point out that Agile promotes the concept of continuous
improvement, the framework itself continues to be evaluated and will likely
evolve just as other exam specifications and methodologies have.
 One such variation of Agile that is gaining acceptance in large organizations is

the Scaled Agile Framework®
 The framework (pronounced SAFe™) is an interactive knowledge base for
implementing agile practices at enterprise scale. It is intended to apply the
disciplines of agile allow for repeatability from the smallest of teams to the
largest of companies.
• For more information:
▫ Agile Software Requirements: Lean Requirements for Teams Programs and the
Enterprise (2011) by Dean Leffingwell
▫ http://scaledagileframework.com/
© BetterPM.com
Sample Exam Questions
 When is the best time for the project team to come together to review what
went well and how they can improve next time?
•During the daily standup
•In the retrospective meeting
•The weekly Scrum summary meeting
•The team lunch
Which of the following least describes the Agile development framework?
•Emergent
•Self-organizing
•Rigid
•Empirical
An Agile team can best be described as
•Highly skilled professionals who refuse to provide documentation
•A cross-functional team that knows how to resolve conflict
•A well-organized team that is managed by a product manager
•A cross-functional team that avoids conflict through planning
© BetterPM.com
 A story card is most likely to contain
•Assignments for the developer
• Identification of required velocity
•Specifics about the implementation of project
•The desired end result of the customer
Which value is not used in estimating story points?
•5
•20
•60
•3
© BetterPM.com
Module 2: Agile in Action

Module Overview
This module takes a deeper dive into the day-to-day events of the Agile
framework. We will present the specific tools, techniques and meetings used by
the agile practitioner.
Value-based analysis
▫ Introduction
▫ Value and quality with charters and incremental releases
▫ Value-based prioritization and agile projects
▫ Value-driven planning versus plan-driven planning
▫ Investment appraisal methods
▫ Regulatory driven
▫ Customer driven
▫ Prioritization methods (MMF, MoSCoW)
1. Value Stream Analysis
▫ Value-stream analysis
▫ Value-stream mapping
© BetterPM.com 62
Module Objectives
At the conclusion of this module, you should be able to:
 Assess Ways to Maximize Value and Minimize Waste

 Discuss How to Increase Value through Quality
 Compare Value to Anti-Value
 Interpret Release Early, Release Often
 Describe Value Stream Analysis
 Optimize the Value Stream
 Demonstrate Value-Based Prioritization
 Illustrate Financial Operational Efficiency
© BetterPM.com 63
Scrum Roles
Recall from Module 1 the specific
roles on an Agile team
The primary role responsible to the

project in terms of leadership is the
Scrum Master, which we will discuss Scrum
Team
on the following slide. Master
Members
Scrum Roles Product

Owner
Users
Stakeholders
© BetterPM.com
The Scrum Master
The Scrum Master is responsible for
 The success of SCRUM
 Establishing SCRUM practices and rules, shielding the team and removing obstacles
 Representing management to the project
 Running the Daily Scrum.
According to Schwaber and Sutherland

in The Scrum Guide:
A strong Scrum Master is:
“The Scrum Master is responsible for • A good situational leader
ensuring Scrum is understood and • A guru
enacted. Scrum Masters do this by • A friend to the team
ensuring that the Scrum Team adheres
to Scrum theory, practices, and rules. • An artist and SME in Agile
The Scrum Master is a servant-leader • A “servant leader”
for the Scrum Team.”
© BetterPM.com
User Stories
As the project commences, the scope of work comes from the product backlog,
which we discussed in Module 1. But what determines what gets into the
backlog? User stories are the backbone of what becomes a part of the backlog.
It’s a device used by agile to gather the requirements that are needed to
eventually begin development of a feature.
 The user story is used to capture the customer’s (or

your internal stakeholder’s) desired end result. Information on a
Story Card:
 Captures the “Who, What and Why” of a
requirement in a simple way. As a: ________
I want to:______
 It is the primary task of the product manager to So that:________
ensure stories are captured.
 One tool used is a simple document template called

a Story Card.
© BetterPM.com
Estimating User Stories
Before the work can begin, estimates must be put against the user stories to allow
for proper forecasting of the work.
A user story is the start of the input for determining what to develop. But just as
with other methodologies and disciplines, you must have an estimate of the work
before you assign the work and provide a realistic timeline to your stakeholders.
 Teams use relative estimating to estimate the user story or product backlog
 The unit of measure is the Story Point
 Why not “Man Hours?”
• Your Product Manager speaks your stakeholders' language and should be able
to translate between story points and man-hours (or other units) as needed.
 Teams use devices like the Fibonacci sequence (1,2,3,5,8) as the estimating
standard for near-term work (sprints within current minor release) and 13, 20,
40, 100 to represent future work.
© BetterPM.com
Estimating User Stories/Backlog
Most User Stories will fall here. Represents
full functionality that can be accomplished in a sprint.
User stories in future major releases
1 2 3 5 8 13 20 40 100
Epic Level
User stories in current minor releases
Team cannot
estimate
Large User
Defects, small enhancements, etc. effectively given
Stories current
May or may not Understanding of
need to be work.
decomposed
further. Very large user stories that
the team can handle but
will need to break down by
decomposition.
© BetterPM.com
Product Backlog – Estimating Stories
A C D E
B
Example: Consider five stories, each of varying size.

 In comparing the stories we want to determine a baseline first (i.e. A story
worth 2 points).
 Looking at the 5 stories we would say that story D represents a size that is not
the largest nor the smallest, so we will say story D is 2 points.
 Now that we have a baseline we can determine the points for the other
stories:
 Stories C and E could be 1 point. Story A 5 is points, and story B is 13 points.
© BetterPM.com
Estimating Tools: Planning Poker
A technique that is common in the agile
framework is the empowerment of the team
to contribute to the estimating process. By
using members of the team to collaborate on
estimates, a more realistic picture emerges of
the true scope of work and the time required
to accomplish it. Planning Poker is one such
method:
 Individual stories are presented for

estimation.
 After a period of discussion, each
participant chooses from his own deck the
numbered card that represents his When considering the
estimate of how much work is involved in work effort, one must think
the story under discussion. in terms of ideal time that
 All estimates are kept private until each the work would take in an
participant has chosen a card. uninterrupted setting.
 At that time, all estimates are revealed
and discussion can begin again.
© BetterPM.com
Sprint
Once the work has been broken down and it’s determined what will be addressed
first, the work is packaged into a fixed unit of time called a sprint. The packaging
of this work is known as Sprint Planning. Below are the characteristics of a sprint:
 A fixed period of nn days to develop a deliverable product.
• New teams should start with a smaller period such as 1 week, and then move up
accordingly.
 The Sprint includes design, coding, testing, and documentation; as well as
build and deploy.
 Once a Sprint has started only the Scrum Team can add or remove items in
Sprint backlog. No interference, even from the VP or CEO of the company,
should be allowed to interrupt a sprint or add work.
 The Sprint Goal is to complete all items in the Sprint Backlog and demo them
when sprint completes.
 Abnormal termination of Sprint is called for when the Sprint Goal no longer
makes sense.
© BetterPM.com
Sprint
 Any work not accomplished in the sprint is sent back to the sprint backlog,
which is used as an input for the next round of sprint planning.
 Sprints are iterations – in fact, you will see terminology such as “Sprint
Planning” and “Iteration Planning.” These terms are equivalents of each other.
The following slide shows the lifecycle of a sprint and its components.
© BetterPM.com
Anatomy of a Sprint
Sprint Planning
Sprint Retrospective
Sprint
Review
Part of Product
backlog becomes
Sprint backlog.
2-4 week duration
Release every sprint Daily Scrum every 24 hours
© BetterPM.com
Sprint Planning
The Goal is to create a Sprint Backlog
 Determine resource availability
 Review Stories by priority
 Stories are broken down into tasks
 Team members pick tasks based on availability, knowledge level, and length of
sprint
 Team provides actual estimates for the tasks
 Team ensures all work can be completed within the Sprint
On the following slide is an example of a sprint backlog as an output of the

planning process.
© BetterPM.com
Example of the Sprint Backlog
 Story one - 40 points
“Financial analyst wants to see six
quarters into the future and two
quarters in the past so that she can
view results and forecasts in the same Units of Value
screen.”
Stories are estimated in a unit of
 Story two - 5 points
points, using the Fibonacci sequence as
“A gift giver wants to see which items
their recipient has already received we showed earlier.
from his registry so that he does not The tasks and the effort required to
end up buying him a gift that has complete the story will not list hours as
already been purchased.”
a unit of value, although efforts such as
 Story three – 8 points
planning poker will generally cause you
“A Tier-I customer support rep needs to
see all open trouble tickets in one
to think of the effort involved when
single page sorted by oldest modified estimating your stories.
date so that he knows which issue
should receive the next assignment.”
Always compare estimates with each resource’s availability to the Sprint to
ensure all work can be completed.
© BetterPM.com
Burn-down Chart
The agile burn down chart is essential for a team to see what progress is made
during each sprint. The goal is to “burn down” the work and track actuals against
the plan, culminating at the end of the time-boxed sprint with no remaining tasks.
100
90
80
Remaining Effort
70
60
Planned
50
Actual
40
30
20
10
0
1 2 3 4 5 6 7 8 9 10 11
Iteration Timeline/Sprint
© BetterPM.com 76
Daily Scrum Meeting
A key component in the successful tracking of the execution of a sprint is known
as the Daily Scrum meeting.
On each day of a sprint, the team meets – preferably at the same time of day and
in the same room every time – and reviews the progress of the project.
If you recall the analogy of the chickens and pigs in module one, you know that
agile places emphasis on the importance of committed individuals on the project
Only committed team members are permitted the chance to speak and interact in
the daily scrum, which means only the direct team may attend and speak in the
daily scrum. It is not a meeting for stakeholders or casual observers to attend.
On the following slide is a listing of the key characteristics of the daily scrum.
© BetterPM.com
Daily Scrum Meeting
Daily 15 minute status meeting
Also known as the stand up meeting
Team stands in a circle facing each other
Each team member answers 3 questions:
 What have you done since yesterday?
 What will you do by this time tomorrow?
 Is there anything you need help resolving?
Use of the Sprint Burn-down chart is a key tool used
In the meeting.
A reminder that other

Agile methodologies may
refer to the Daily Scrum as
the Daily Stand-up
Meeting.
© BetterPM.com
Things to Watch out for in the Daily Scrum
To prevent a loss of momentum, the following situations should be

mitigated:
• External stakeholders should not be allowed in the meeting. If they arrive
unannounced, they should be asked to observe only, not to speak.
• Although the team is empowered to make decisions, groupthink should
not occur, nor should they make technical decisions without the
agreement by the appropriate domain expert.
• Direct requests for status from external stakeholders risks impeding the
structure and intent of the daily standup.
• The product backlog should be reviewed regularly. So too should the burn-
down chart. If this data is not referenced in the meeting, there is a risk that
the team will lose focus during the sprint.
© BetterPM.com 79
Additional Agile Tools and Techniques
 In the following pages we showcase a number of options that are available to

an organization as they consider adopting Agile.
 Note that not all of these tools and techniques are mandatory components of
the framework; some companies may choose to use them or other variations.
In Module 8 we discuss the concept of Method Tailoring, which actually
encourages the use of variations.
© BetterPM.com
Agile Modeling
 Agile Modeling (AM) is both a management style and a system
of discipline used for effective modeling and documentation
of software-based systems. It is not a complete software
process but it does complement the agile framework with
recommendations for effective communication and
documentation tools.
 The term was coined in 2002 by Scott W. Ambler in his book,
Agile Modeling: Effective Practices for eXtreme Programming
and the Unified Process. Ambler continues to evolve the
concept on his web site, http://www.agilemodeling.com
 Ambler states that it’s “an art, not a science,” that’s a collection of values, principles,
and practices* for modeling software that can be applied on a software development
project in an effective and light-weight manner
 Assumes simplicity and embraces change.
 There are a number of specific best practices in the use of agile modeling, which are
discussed on the next slide.
References:
http://www.wiley.com/WileyCDA/WileyTitle/productCd-047127190X.html
Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. Ambler, Scott W. John
Wiley & Sons, 2002.
© BetterPM.com
Agile Modeling Characteristics
 Active stakeholder participation with a high return on investment (ROI)
• Stakeholders are expected to engage in a timely manner.
 The Unified Modeling Language (UML) is suggested as one such tool for
modeling
 Initial architecting of the solution to achieve a high level vision.
 Iteration Modeling - The idea is that during the start of the iteration, you do
just enough get-ahead work to confirm the design.
 Just Barely Good Enough items – building a model or document that is just
sufficient enough for the situation and no more. Ambler suggests to “model
with a purpose.”
 Lookahead modeling – Complex requirements may require initial investigation
well upstream to reduce overall project risk.
 Model storming – Reviewing a deliverable during an iteration to explore the
details of a requirement.
© BetterPM.com
Agile Modeling Characteristics
 Multiple models – Using the right model for the right situation at hand. Since
software can be complex, it is suggested that no one model can
comprehensively address the entire solution.
 Prioritized Requirements
 Requirements Envisioning – Taking time to review the scope and determine
the prioritization.
 Test-Driven Development – Writing a small test and then immediately develop
just enough to be able to perform the test.
Agile Modeling is a discipline that is still under development. The key text is
referenced here:
Agile Modeling: Effective Practices for Extreme Programming and the Unified
Process John Wiley & Sons ISBN#: 0471202827
© BetterPM.com
Empirical Process Control
Empirical process control is used by scrum through a process of frequent
inspection and adaptation. Because our business reality includes processes that
are not always perfectly defined, and can generate unpredictable results,
adaptable and iterative frameworks such as agile still rely on controls.
 There are three key elements in the model:
• Transparency: The parts of the process that affect the outcome must be openly
observable at every step until delivery to the customer.
▫ Examples of this used in scrum include information radiators (presented in an upcoming
module,) a publicly viewable backlog, and sprint reviews and retrospectives.
• Inspection: The process by which you take your observations from the transparent
information and envision how the product performs in the business workflow.
Deliverables must be inspected frequently so that variances can be detected.
• Adaptation: The process by which you make adjustments based on your
inspections, and then making those adjustments serve as continuous
improvements.
Reference: Schwaber, Ken; Beedle, Mike (2002), Agile Software Development with Scrum, Upper Saddle River:
Prentice Hall, ISBN 0-13-067634-9
© BetterPM.com
Velocity Tracking
The word “velocity” is often used during an agile project. The main idea behind
velocity is to help teams estimate how much work they can complete in a given
time period based on how quickly similar work was previously completed.
Terms used in Velocity Tracking

Unit of Work
The unit chosen to measure relative progress among the team. Units of work can either be
abstract – like story points – or they can be more specific, such as hours. Note, however,
that the use of hours is generally discouraged in agile.
Interval
The interval is the duration of each iteration in the development process that we are
measuring velocity against.
The ability to measure velocity improves after a number of iterations are completed. We
will cover velocity in greater detail in subsequent modules.
© BetterPM.com
Module Summary:
Key Concepts and Recommendations
 Agile places a lower priority on tools than on work and communication.
 Agile embraces change while you are working, and is an antithesis to the
waterfall methodology.
 Because it is so dynamic, you must gather rapid feedback on your work.
 Adapt your use of Agile to meet the needs of your company’s environment.
 Central components of agile and scrum are:
•User Stories
•Iterations/Sprints
•The Scrum Master
•The concept of a collaborate team that shares ownership and responsibility.
© BetterPM.com
Module 3: Value Driven Delivery

Module Overview
This module focuses on the PMI-ACP exam’s Value Driven Delivery framework,
including the role of value-based tools and techniques in bridging traditional
project management with agile.
In this module:
1. Value-based analysis
▫ Introduction
▫ Value and quality with charters and incremental releases
▫ Value-based prioritization and agile projects
▫ Value-driven planning versus plan-driven planning
▫ Investment appraisal methods
▫ Regulatory driven
▫ Customer driven
▫ Prioritization methods (MMF, MoSCoW)
▫ Value-stream analysis
▫ Value-stream mapping
© BetterPM.com 88
Module Overview - continued
3. Prioritization
▫ Prioritization models
▫ Determining what to measure and track
▫ Methods of measuring/tracking/prioritizing
▫ Adding value with metrics
4. Incremental Delivery
5. Quantifying Value - financial measurement techniques

▫ Net Present Value
▫ Internal Rate of Return
▫ Return on Investment
▫ Payback Periods
7. Sample exam questions
© BetterPM.com 89
Module Objectives
 Assess Ways to Maximize Value and Minimize Waste

 Discuss How to Increase Value through Quality
 Compare Value to Anti-Value
 Interpret Release Early, Release Often
 Describe Value Stream Analysis
 Optimize the Value Stream
 Demonstrate Value-Based Prioritization
 Illustrate Financial Operational Efficiency
© BetterPM.com 90
1. Value Based Analysis - Introduction
Value based analysis is a combination of financial modeling and strategic decision
making that was introduced in the late 1990s. It was originally developed to serve
as a model for managing investment in reusable software and has subsequently
been modified to apply to different types of IT investments.
Concepts to keep in mind in this section:

• Agile emphasizes value over waste. If something is not in the value stream it is
aggressively taken out or minimized. Waste is considered “Anti Value.”
• Operating under an agile or lean model (discussed in an upcoming module)
supports value based analysis, which requires certain quantitative
measurements (which are covered later in this module.)
• We will continue to contrast Agile with Waterfall. In this module we focus on
plan-driven versus value-driven planning.
For more information: http://www.agilebok.org/index.php?title=Value_Based_Analysis
© BetterPM.com 91
Value Based Analysis – Key Concepts
 Whereas the agile discipline focuses on clarity at the operational level, Value
Based Analysis (VBA) adds to it by striving for clarity in the marketplace.
 In Agile, VBA addresses improvements in process designs, processes and

systems.
 Value based analysis ties together the benefits of the agile discipline and asks
if the improvements can be delivered without reducing the customer’s
expectation of quality, yet still be delivered at a profit to the company.
 The image on the following page shows how different the end result is
between value-driven and plan-driven planning.
© BetterPM.com 92
VBA: Value-driven versus Plan-Driven Planning
Fixed Requirements Resources Time
Waterfall Agile
In comparison with
waterfall, agile flips
the triangle in terms
of what’s fixed and
Value Driven
estimated.
Plan
Driven
Estimated Resources Time Features
© BetterPM.com 93
VBA: Value-driven and Plan-Driven Planning
 Recall the difference between Agile and Waterfall disciplines. Value driven
planning is an adaptive discipline, whereas plan-driven planning is a predictive
approach.
 Plan-driven approaches work hard to enforce scope while value-driven

approaches embrace scope change and address in iterative releases.
 In contrast of the tight controls over the schedule and scope with waterfall,
agile turns the concept upside-down and uses collaborative teams and clear
visibility into progress to focus on the rapid delivery of value.
© BetterPM.com 94
Value Driven Planning
 Value Driven Planning focuses on achieving results as quickly as possible, with
less intense wins occurring over time.
 The largest amount of value is addressed first, as is shown below.
Value
Pay particular attention

to this image; we will
revisit it later in the
course as we discuss
“Just Barely Good
Enough.”
Performance
© BetterPM.com 95
Plan Driven Planning
 Plan Driven Planning focuses on realizing targets and milestones of completion instead
of incremental delivery. It is possible to not see any delivery at all until a first milestone
release well into the project.
 Task lists assembled from the project schedule assist the team in reaching the overall
project objective. This is also known as the Work Breakdown Schedule (WBS)
 Plan Driven planning is very often used in the Waterfall methodology.
Value A rigorous schedule, change control Release

process and risk mitigation strategy exists Milestone
in this stage to help the project reach the
finish line, but no incremental deliveries
occur.
Performance
© BetterPM.com 96
Determining Value
 Value is the relative worth of something in comparison to other items.
 In value driven planning under Agile, the value of a feature is related to the
relative return on investment (ROI) in relation to other prioritized features.
 To deliver value, the feature or product must be relatively greater in its ratio of
value and cost compared to the current state. High value at a high cost may
not be treated by the customer as high value. The higher the ratio, the higher
the value.
Value = Benefits Note that value may be

Cost very subjective in the eyes
of the customer. The agile
practitioner should always
be mindful of the
customer’s requirements.
© BetterPM.com 97
Types of Value
Keep in mind that value can be many things to different people. Although cash flow and
revenue are important to a company, consider these examples.
Type Definition Example
Intrinsic An objective, actual value that Commodities such as precious

has the same value or price metals
among people.
Extrinsic or A subjective value placed on Mementos; family pictures
Instrumental an item due to some external
event or personal experience.
Market The value of an object that Artwork on the secondary
others are willing to pay for in market.
competition.
Book The value as placed by an Kelly Blue Book value of a used
objective third party. car.
© BetterPM.com 98
Anti Value and Risk Mitigation
 Consider that issues and risks exist as potential negative or “anti value” against
your product, which should always be intended to add value.
 Risks erode value and should be mitigated. By minimizing risks (or “anti
value,”) you concurrently maximize the products value.
 Anti value is the antithesis of value. Consider these examples:
Value Anti Value

Water-tight boat hull epoxy Cracks in the hull
Fuel efficient gasoline Rogue particulates from the

refinement process
High strength concrete Ineffective pouring methods
Bug-free product code Incomplete code branches at

launch
© BetterPM.com 99
Quality Management in Agile Processes
Since agile is a focus on frequent and early progress and value to the customer,
you must include quality control in every phase of development, rather than just a
distinct phase of the project.
 Because your product is developed iteratively, every change to it should be
considered potentially harmful to its end state.
 Tools at your disposal are Verification and Validation: independent procedures
that are used together for checking that a product, service, or system meets
requirements and specifications and that it fulfills its intended purpose.
Validation Verification
The assurance that a product, service, The evaluation of whether or not a
or system meets the needs of the product, service, or system complies
customer and other identified with a regulation, requirement,
stakeholders. It often involves specification, or imposed condition. It
acceptance and suitability with external is often an internal process. Contrast
customers. Contrast with verification. with validation
From A Guide to the Project Management Body of Knowledge (PMBOK Guide) 4th edition
© BetterPM.com 100
Value stream analysis is a technique used to analyze and design the flow of
materials and information required to bring a product or service to a consumer. It
takes an overarching view of the entire product and its lifecycle to ensure that
waste is eliminated everywhere that it occurs.
In this section we will:

 Explain the value stream
 Show how to map the current state of a value stream
 Guide you through the process of improving the value stream using agile tools
and techniques.
© BetterPM.com 101
Value Stream Analysis
 Value Stream Defined: A value stream is described as any process where
materials or information flow to bring a product or service to a consumer. It is
the sequence of steps in the production workflow, from start to finish.
 Value Stream Analysis Defined: Value Stream Analysis is a business process
planning event driven by changes to customer demand or as part of a regular
review cycle and is a key tool in the development or enhancement of a
process. It provides a documentable standard for the continuous improvement
process.
 Value Stream Mapping (VSM) is a process tool that arose from Lean (which we
will cover in a subsequent module) that can help teams get an understanding
of where some of their biggest problems are. When done correctly, value
stream maps are produced by collaborative, high touch/low fanfare sessions
that can lightly apply a structured discipline to identify waste and potential
areas for improvement.
Your goal as agile Practitioner: continually add value at every step until your work
is complete
Reference: http://www.endeavourengineeringtech.com/services/value-stream-analysis-lean-management
© BetterPM.com 102
Creating a Value Stream Map (1 of 3)
Creating a VSM provides the agile practitioner the ability to find opportunity to
eliminate waste and improve process efficiency.
Consider the example of purchasing a car:

1. Identify the starting point of the process (who initiates) it and the end point
(who gets the end result) of the process.
You in
You
your car
2. Identify the high level steps, inventories and queues through the process
focusing on the primary flow
Car Financing You in

You Closing
Selection application your car
© BetterPM.com 103
3. Identify any supporting groups and alternative flows. Think about what
happens if there is re-work or a change of plans.
Denial of financing:
Look for a different model

You Closing
Dealers Sales
Keep in mind that the value stream rarely is point-to-point with no iterations or
alternate branches. Be mindful of this as you perform a real-life map.
© BetterPM.com 104
4. Measure the Value Adding and Non Value Adding activities, calculate
efficiencies, identifying waste, bottlenecks and improvement actions.

You Closing
Dealers Sales
4 hours 1 hour 2 hours 1 hour

Value Add
Non Value Add
1 day 1 hour 1 hour

Total Cycle Time = Value Add + Non Value Add Time Total Cycle Time = 11 hours
Process Cycle Efficiency = Total Value Add Time Process Cycle Efficiency = 8 =73%
Total Cycle Time 11
© BetterPM.com
Value Stream Mapping – Other Considerations
 In the preceding example, consider other options or scenarios. For instance:

• Think of the supply chain between Sales and Operations groups.
• Current state process maps that your company uses to document internal service
levels.
• In the world of software management, think about the value stream that’s involved
with software upgrades and patches. Can your current state be optimized following
a mapping of its value stream?
© BetterPM.com 106
Ways to Optimize the Value Stream
 Emergent Design – Emergent design is intended to deliver small chunks of
deliverables with business value. Once a number of iterations has occurred,
the commonality is reviewed to establish a final design. Consider the following:
• A development organization starts delivering functionality and lets the design
emerge. Development will take a piece of functionality A and implement it using
best practices and proper test coverage and then move on to delivering
functionality B. Once B is built, or while it is being built, the organization will look at
what A and B have in common and refactor out the commonality, allowing the
design to emerge.
 Acceptance Testing: An acceptance test is a formal description of the behavior
of a software product that is intended to confirm if the requirements or
specification are met. Acceptance testing typically expressed as an example or
a usage scenario.
• In agile, writing the test precedes writing the code. In a subsequent module we will
discuss Test Driven Development.
For more information on Emergent Design: See this Wikipedia article: http://en.wikipedia.org/wiki/Emergent_Design
© BetterPM.com 107
Tools Used to Optimize the Value Stream
When optimizing the value stream of software, you’ll often use key terms such as
these below:
 Cycle Time: The number of days needed between feature specification and
production delivery. A shorter cycle indicates a healthier project.
 Lead Time: The time between the initiation and delivery of a User Story
Other Tools
In the following slides we showcase a number of agile concepts and tools used to
measure and optimize the value stream. These include Just In Time and its use of
Kanban signals.
© BetterPM.com 108
Just in Time (JIT)
 Just in Time is a production approach that is intended to improve ROI by
reducing in-process inventory and associated inventory and overhead costs.
 JIT is used by Agile teams as a mechanism to achieve continuous improvement.
 Relies on signals, or Kanbans, to alert the production team of what’s needed
next.
Goals of JIT in Agile

1. Eliminate Waste
2. Utilize a pull-type system of demand
3. Reduce lot size, coding handoffs and rework
4. Zero defects
© BetterPM.com 109
Kanban
 Kanban is a scheduling system used in Lean and Just It Time production so that
inventory levels can be aligned with consumption.
 Controls the production chain to ensure that not too much or too little of
something is produced.
 Is not an inventory control system.
 Advantages:
How it Works
• Dramatically reduce inventory levels
• Increase inventory turnover “Signals” are used to tell the
• Enhance supplier/customer relationships producer what to produce,
• Improve the accuracy of manufacturing schedules. when to start, and what the
quantity should be.
© BetterPM.com 110
Kanban Cards and Boards
 The Kanban card serves as the signaling device to alert producers what to
produce, in what quantity, and when to begin production.
 A Kanban board visually presents the supply chain showing individual statuses.
 Today, ERP systems such as SAP, Oracle and others use workflows and email
notifications to generate the production signal.
© BetterPM.com 111
3. Decomposition
Let’s face it: businesses are complex. Software is complex. A user’s requirement is
complex. The opportunity to miss the requirement is large.
Agile places emphasis on incremental delivery and Rough Design Up Front (versus
Big Design Up Front,) but the agile practitioner still needs to be sure that the right
features are being developed.
A key process used by agile that allows the team to function in a way that adds
value to the project comes by way of decomposition of the elements of
requirements, known as user stories.
Decomposing a requirement involves taking the result your user is looking for
(stated as a User Story) and breaking it down into a number of tasks that the team
can work on individually.
© BetterPM.com 112
Decomposition Techniques in Agile
Recall from Module 1 that a user story is a requirement of a system to be
developed, written in a simple format such as,
“As a” (User Role)

“I want” (goal)
“So that “ (business value)
Each user story must be estimated by the team and prioritized, but it must also be
small enough to be delivered in a sprint. This is a necessity if you want to achieve
real benefits in terms of value delivery, visibility, flexibility, feedback and
continuous improvement.
In the following slides we present a process by which you can break down a user
story into the tasks necessary to be delivered in a sprint.
© BetterPM.com 113
Decomposition Steps
There are a number of ways in which you can organize and decompose your
stories:
Treat the user story like steps in a workflow
Getting from Point A to Point Z usually requires a review of the steps (or workflow) in a
process, and it’s rarely if ever a straight line. A business requirement or user story can likely
be broken down into smaller steps so that it can be developed incrementally. Each step
might be a separate user story.
Turn the story into a scenario

The story may have come to you representing only the most likely or obvious path to the
end state. Think about other people who play the role of your user. Consider using branch
logic to be sure that other scenarios involved in getting to the end state are accounted for.
You can also use a persona (reviewed later in this course) to ensure that every aspect of the
user story is accounted for.
© BetterPM.com 114
Decomposition Steps
Sequence your Scenarios
Place your stories and their scenarios into sequence so that you can reach greater precision
and improve the planning process. Follow-on features would then likely be more apt to be
chosen for development in later sprints.
Split your story into operations

One of the best ways to decompose is to split the story into operations. In software
development, features involving Create, Retrieve, Update, Delete (CRUD) operations are an
excellent way to reduce the story into smaller pieces because you can do so in a repeatable
fashion.
Separate your story by sizes or type

Your story may be prone to being broken up either by language or by a unit of measure that
is conducive to having separate pieces.
© BetterPM.com 115
Decomposition Steps: Using Personas
When documenting a user story, a powerful tool to help ensure that all
requirements are met is to use a persona. A persona is a personalized, yet
fictitious account of what the archetypical user might be like when using your
product.
Some characteristics of personas in Agile:
 Personas are representative of people, but they are not living, named people.
 A benefit is that personas are more specific that role-based use cases. For
instance, “bank teller” would not be a persona. “Judith McNight, 63, 10-year
veteran teller at ABC Bank” would be the start of a persona.
 The persona is personalized and often reads like a biography of a fictional
person.
 The persona is meant to allow for personality and background types of the
users. In the example of a bank teller, you would want to create multiple
personas in order to ensure you’ve captured all requirements.
 It is common to include clip art of an individual to help personalize the persona
even more.
© BetterPM.com
Other Decomposition Steps
Levels of complexity or knowledge
You can break down your stories by either the knowledge that is acquired on a feature or
by the level of detail that a user consumes the product. Consider software where users
make use of only 80% of the features, yet advanced users of the software use 100% of the
features as super users. The latter group would likely involve a separate story to document.
Separate your story by expected quality

Elements of expected user satisfaction will help you determine how fine to break down the
user stories. Concepts such as performance or usability are often not directly spoken and
referenced in the story, but the connotation is there.
Reference: http://www.agile-ux.com/2011/04/19/10-strategies-to-split-large-user-stories/
© BetterPM.com 117
4. How Do you Know what to Build?
 In order to deliver incremental releases of value to the customer, it’s necessary
to have your finger on the pulse of the client. This will help you determine not
only what to build, but in what priority.
 The agile practitioner must constantly strive to place emphasis on the value to
be delivered to the customer.
© BetterPM.com 118
Positive Value – The Voice of the Customer
 The Voice of the Customer (VOC) is a market research technique developed in
the 1980s by Professor Noriaki Kano. It classifies customer preferences into
five categories that produce a set of customer requirements, organized into a
hierarchical structure, and is then prioritized in terms of relative importance
and satisfaction.
 Feedback loops are an important part of an agile team’s arsenal. By prioritizing
features based on customer requirements, positive ROI can result from
product development.
 One tool to measure the VOC is the Kano Model, whose goal is to determine
overall customer satisfaction. The Kano model offers some insight into the
product attributes which are perceived to be important to customers. We will
review the Kano model in an upcoming slide.
© BetterPM.com 119
Customer-Value Prioritization Approaches
Prioritization is a major concept of agile practice. Prioritization determines the
order the agile team will work on the requirements. Prioritization models include:
 MoSCoW prioritization
• Must - The must requirements is given the top most priority
• Should -Next priority is given to the requirements that are high desirable, though
not mandatory
• Could - The next priority is given to the requirement that are nice to have
• Won’t -The final consideration is given to the requirements which will not work in
the process at that point of time. (This is also known as “Would,” and always
receives the lowest rank order.)
 The relative weighting method
• Relative weighing scheme is a simple model where prioritization is done based
upon all the factors mentioned below.
▫ Benefit from having the feature
▫ Penalty for not having the feature
▫ Cost of producing the feature
▫ Risk incurred in producing the feature
© BetterPM.com 120
Customer-Value Prioritization Approaches
 Kano Model of Prioritization
• This prioritization technique leverages the three attributes of “Basic Expectations,”
“Performance Payoff” and “Excitement Generators” that take customer
satisfaction from disappointment to not happy to getting delighted.
Attractive Quality – Provides customer satisfaction

when achieved fully, but does not dissatisfy when not
achieved. These attributes are not normally expected.
One-Dimensional Quality – Provides customer
satisfaction when fulfilled and dissatisfaction when The Kano Model uses
not fulfilled. two questionnaires
Must-Be Quality – Attributes are taken for granted and an evaluation
when not fulfilled but result in dissatisfaction when table to classify the
not fulfilled. requirements into
Indifferent Quality – Attributes that are neither good categories.
nor bad, and do not influence customer satisfaction
or dissatisfaction.
Reverse Quality – A high degree of product that does
not satisfy every customer, as individual expectations Reference: More information on the Kano
model can be found in this Wikipedia article:
are different. http://en.wikipedia.org/wiki/Kano_model
© BetterPM.com 121
The Kano Model of Customer Satisfaction
High Excitement
Customer
fully satisfied
Customer Satisfaction
Performance
Needs
Product is Customer Product fully

dysfunctional Indifference dysfunctional
Basic
Needs
Customer
Low
dissatisfied
Absent Quality Provided
© BetterPM.com
Qualities of Desirable VOC Data
 Credibility: How widely accepted is the measure? Does it have a good track
record of results? Is it based on a scientifically and academically rigorous
methodology? Will management trust it? Is there proof that it is tied to
financial results?
 Reliability: Is it a consistent standard that can be applied across the customer
lifecycle and multiple channels?
 Precision: Is it specific enough to provide insight? Does it use multiple related
questions to deliver greater accuracy and insight?
© BetterPM.com 123
Qualities of Desirable VOC Data
 Accuracy: Is the measurement right? Is it representative of the entire customer
base, or just an outspoken minority? Do the questions capture self-reported
importance or can they derive importance based on what customers say? Does
it have an acceptable margin of error and realistic sample sizes?
 Actionability: Does it provide any insight into what can be done to encourage
customers to be loyal and to purchase? Does it prioritize improvements
according to biggest impacts?
 Ability to Predict: Can it project the future behaviors of the customer based on
their satisfaction?
From Ernan Roman, ERDM.com (2010): Voice of Customer (VOC) Relationship

Research
http://www.erdm.com/creating-integrated-marketing-solutions.05.php5
© BetterPM.com 124
5. Incremental Delivery
A key difference between Agile and Waterfall is the delivery of product in
incremental segments, rather than all at once in a major release from Waterfall.
Incremental delivery creates quick wins for the customer and provides
opportunity to course correct if requirements were not adequately captured.
In the upcoming pages we will present an in-depth look at incremental delivery.
© BetterPM.com 125
The Importance of Incremental Releases
 Agile teams should release products and software as early as possible and
during frequent iterative releases. This mitigates risks, gets products to market
earlier, and keeps your stakeholders engaged.
 The longer a project is run, the greater the risk of failure, changed
requirements and lost opportunities.
 Incremental delivery allows the customer to be engaged in the development
process to ensure that they get the product they want.
 Incremental delivery allows for higher long-term value (next page.)
© BetterPM.com 126
Incremental Delivery
Long-term value
Compared to a increases as a
Waterfall approach, result of
incremental delivery planning.
provides quick wins and
a steady stream of value
add.
Value
Solid lines represent
releasable deliverables
to the customer.
ROI remains high in the

early stages of planning
Time
© BetterPM.com 127
6. Quantifying Value
At the start of this module we mentioned that it’s not enough to deliver product
in a lean, efficient way to produce value. We need to be able to deliver value to
the business and executive stakeholders, who are interested not in the number of
backlog items worked down but in the financial and strategic value to the
customer or the firm.
In other words: if you can’t measure it, you can’t manage it. To know you are
delivering value, you need to know now to measure the expected value.
In the following pages we review a number of methods used to quantify value to

the business.
© BetterPM.com 128
Net Present Value (NPV)
 Net present value (NPV) or net present worth (NPW) of a time series of cash
flows, both incoming and outgoing, is defined as the sum of the present values
(PVs) of the individual cash flows of the same entity.
 A positive NPV means that the project is expected to add value to the firm and
will therefore increase the wealth of the owners.
 Calculates how much money you must invest today to realize a specific amount
tomorrow.
 Since our goal is to increase owner wealth, NPV is a direct measure of how well
this project will meet our goal.
Decision Rule
Given the (period, cash flow) pairs ( t , Rt ) where
If the NPV is
N is the total number of periods, the net present positive, accept the
value is given by: project
© BetterPM.com
Internal Rate of Return (IRR)
 Internal Rate of return is a rate of return used in capital budgeting to measure
and compare the profitability of investments. It is also called the discounted
cash flow rate of return (DCFROR) or the rate of return (ROR).
 IRR is the return that makes the NPV = 0
 This is the most important alternative to NPV
 It is often used in practice and is intuitively appealing
 It is based entirely on the estimated cash flows and is independent of interest
rates found elsewhere
Decision Rule
Accept the project if
the IRR is greater
than the required
return
© BetterPM.com
Return on Investment (ROI)
 Return on Investment (ROI) is a performance measure used to evaluate the
efficiency of an investment or to compare the efficiency of a number of
different investments. It is one way of considering profits in relation to capital
invested.
 Measures how quickly the project expense will result in an increase in value.
 In Agile retrospective meetings, ROI calculations can measure the effectiveness
of project duration (from development to release to market)
Return on Investment formula

(%) = Net profit / Investment × 100 Decision Rule
ROI has no concrete

decision point, as it is
a more subjectively
used by companies.
© BetterPM.com
Calculating a Payback Period
 A payback period is a the amount of time required to earn back the initial
project investment. Payback periods are usually expressed in years.
 Payback period is easy to use and simple to understand, but has significant
limitations and should not be used alone for making decisions.
Calculation: Payback Period = (p - n)÷p + ny = 1 + ny - n÷p
Where
ny= The number of years after the initial investment at which the last negative value of cumulative cash flow occurs.
n= The value of cash flow at which the last negative value of cumulative cash flow occurs.
p= The value of cash flow at which the first positive value of cumulative cash flow occurs.
Advantages Disadvantages Decision Rule

Easy to use and understand Ignores time value of money,
opportunity cost, risk and As a stand-alone tool to
financing compare an investment to
Useful in relative Should not be used in "doing nothing,“ payback
comparisons to other isolation period has no explicit
payback periods criteria for decision-making
© BetterPM.com
Discount Payback Period
 The discounted payback period formula takes into account the time value of
the money.
 In contrast, a normal payback period formula just uses the initial cost of
investment and the amount of time it will take to recover the cost.
 A discounted payback period formula discounts the amount recovered,
resulting in a longer payback period.
The formula: years of full recovery + cumulative cash flow/unrecovered
Citation: http://www.reference.com/motif/science/discounted-payback-period-formula
© BetterPM.com 133
 Which equation most accurately expresses value?
•Value = Benefits/Cost
•Value = (Benefits-Cost)
•Value = Benefits x Cost
•Value = Benefits – (2 x cost)
Which of the following best describes an agile methodology for modeling
software systems?
•Extreme Programming
•Agile UML
•Agile Modeling
•OpenUP
The CEO is visiting the factory floor and is curious what product the supply chain
owner is soon to be in need of reordering. What should he look for?
•The results of the latest decomposition analysis.
•Kanban board
•The latest ROI analysis
•The product backlog
© BetterPM.com
7. Sample Exam Questions
 A Scrum Master understands that:
•The project baseline cannot change.
•User stories properly decomposed will result in a project with little or no change.
•Changes on a project should be held back for a future release.
•Change on a project is inevitable
Which statement is true?
•Incremental delivery always exceeds waterfall-based delivery
•Incremental delivery is more expensive than delivering a single, major release.
•Incremental delivery allows for changes and missed requirements to be caught as
early as possible.
•ROI is low in the early stages of incremental delivery.
© BetterPM.com
Module 4: Stakeholder Engagement

Module Overview
This module focuses on the PMI-ACP exam’s Stakeholder Engagement knowledge
domain, which focuses on emotional intelligence, collaboration, adaptive
leadership, negotiation, conflict resolution and servant leadership
In this module:
1. Stakeholder needs
2. Stakeholder involvement
3. Stakeholder expectation
© BetterPM.com 137
Module Objectives
 Identify and engage effective and empowered business stakeholders who are
engaged with the team in order to ensure that the team is knowledgeable
about an agreed, prioritized feature set reflecting all stakeholders’ interests.
 Identify and engage all stakeholders (current and future) by promoting
knowledge sharing early and throughout the project to ensure the unimpeded
flow of value throughout the lifespan of the project.
 Establish stakeholder relationships by forming a working agreement among all
stakeholders to promote effective collaboration and participation of
stakeholders on project activities.
 Maintain proper stakeholders’ involvement by continually assessing the
changes in the project and organization that affect the stakeholder landscape
in order to ensure new stakeholders on the project are appropriately engaged.
© BetterPM.com 138
Module Objectives (continued)
 Establish and maintain a shared understanding of success criteria, deliverables

and acceptable trade-offs by facilitating awareness among stakeholders in
order to align expectations and build trust.
 Communicate team progress and development capabilities in order to help the
business stakeholders make informed decisions about scope, time, and cost.
 Manage stakeholders’ expectations around minimal/most likely/optimal
project outcomes, balancing accuracy and precision, so stakeholders have
greater assurance that those outcomes will help them meet their business
objectives.
© BetterPM.com 139
Section 1. Stakeholder Needs
Most project management disciplines adhere to strong stakeholder management
directives. It is no different for the agile practitioner.
But what is a stakeholder, and what are their needs?
In this section we’ll identify:

• Identify who are the stakeholders.
• How to practice continuous engagement with your stakeholders.
• Best practices for communication and collaboration with your stakeholders.
© BetterPM.com 140
Who are the Stakeholders?
Stakeholders can be anyone on
the project, either internal or
external to your organization.
Community
Identify as much information
about your stakeholders as is
necessary so that you can
determine their potential Customers
support.
Colleagues
You should identify all of your
stakeholders as being neutral, a
supporter, a negative influence
or one with a certain vested
interest on the project.
© BetterPM.com 141
Why is Stakeholder Participation Important?
People are generally not very good at defining what they want, but they are good
at indicating what they think they want and what constitutes a successful
product.
One key necessity in working with your stakeholders is to establish requirements:
As opposed to Waterfall where “Big Design Up Front (BDUF)” can lead to a “If you
don’t ask for it you won’t get it” approach, Agile involves stakeholders in a
different way: It is much easier to fix a requirements bug in the requirements
phase than a bug in the development phase. Sufficient design is completed up
front to provide a framework on which to build in the design detail as the project
progresses. This is known as “Rough Design Up Front (RDUF.)”
© BetterPM.com 142
Empowering your Stakeholders
As opposed to other project methodologies for project managers where
stakeholder management is recommended, the agile practitioner should engage
in stakeholder empowerment.
An engaged stakeholder is more likely to help keep the project on course.
A key principle of Agile is live communication. It’s important to note that face-to-
face communication is always the preferred mechanism. This is true with
empowerment of any stakeholder.
Express with your stakeholders that business involvement is critical throughout

the project.
You can also empower your business stakeholders by inviting them to design
reviews and retrospectives.
143
© Better PM.com / Innate Images, LLC
How can a Stakeholder Raise an Issue?
Stakeholder empowerment can be encouraged by promoting the following tools
and processes:
 Use stand-up meetings to discuss the product backlog (shown below)
 Retrospectives are a good way to communicate and improve for next time.
 Issues may be placed on a visible task board for all to see.
 But the stakeholder should NOT attend the standup meeting unless they are a team
member.
Story To Do In Dev Test Complete

As a User, I… Code the Test the Test the Test the Test the Code the
As a User, I… Code the Test the Code the Test the Code the Code the
As a User, I… Code the Test the Code the Code the Test the Code the
As a User, I… Code the Test the

4 points 8 points 5 points
144
Stakeholder Roles
Stakeholders can be aligned to specific roles on the project, but keep in mind it’s
not always easy to immediately identify all stakeholders at the onset.
As you identify your stakeholders:

• Align them to the proper roles of the project: advisor, lead
architect, core end users, team member, etc.
• Determine what is needed from each stakeholder. Determine what
each one brings to the project, and what is required to keep them
empowered.
The primary role they play is in keeping the project on course through what was
chartered. This ensures that maximum value is secured from the product.
145
Help your Stakeholders Ensure Value
Keep your stakeholders empowered so that they may provide maximum value for
your project.
Prioritize your deliverables so that high ROI is derived from the input of your
stakeholders. Remember: Multiple stakeholders may yield multiple priorities.
Make sure you have identified your stakeholders by role, by influence and by
expectations. A prioritized list will ensure that incremental delivery and value is
achieved while providing your end users with the right solution to their needs.
Reference the value stream and map your stakeholders to each phase of it. By
ensuring close and frequent communication, feedback loops in every phase of the
value stream allow for the proper management of change.
146
Types of Stakeholders
1. Business – Sponsors, executives, a steering committee
2. The Customer - Product Management Group or product owners
3. Domain Experts and Subject Matter Experts
4. Developers – Codes, Testers, QA, etc.
5. The End User
In the following pages

we will identify what
each user brings to the
project.
147
Who are stakeholders? (cont’d)
 Example of the relationship between the stakeholders and the project:
Project Stakeholders
Other Operations
Stakeholders Management
Portfolio Functional
Sponsor
Manager Managers
Project Team
Project Other
Program Management Project Sellers/
Manager Team Project Team Business
PMO Manager Members Partners
Project Users/
Management Customers
Office
The Project
Source: A Guide to the Project Management Body of Knowledge (PMBOK® Guide ), 5th Edition (2013 Project Management
Institute, all rights reserved)
© BetterPM.com
Types of Stakeholders – The Business
 The business sets the scope of the project.
1. Determinations are made on market coverage and financial objectives.
2. The business has a wide range of users to draw from to ensure the right scope
decisions are made.
3. The business will make key decisions on what to develop versus what to acquire
 The business is incented to increase its market share through maximizing value
to the customer.
149
Types of Stakeholders – The Customer
 The customer’s role is to ensure that the goals of the project charter are met.
• They put forward the business case required to launch the project.
 The customer is not the end user. The customer’s focus is on ensuring that the
needs of the business are met on time, within budget, and within scope.
• The customer is therefore a likely engaged stakeholder to the agile discipline. They
are highly vested in ensuring that the process supports success.
 The customer is among the very first set of stakeholders that you will engage in
the project, as they will be necessary to support the tools and processes as
they champion the agile discipline to others.
 Your customers are incented by seeing the possibility of bringing new products
to market, which improves their standing in the organization.
150
Types of Stakeholders – Domain Experts
 These people are the technicians and the subject matter experts of the
project. They are the people the business turns to with the expectation of
knowing the technical solutions to solve a business need.
 The Product Manager is one of the trusted domain experts on the project.
 As an agile practitioner, be sure to keep the domain experts communicating on
an equal footing. Problem domain experts and solution domain experts may
require active facilitation by you.
151
Types of Stakeholders – Developers
 The developers are the ones who execute the project from the perspective of
coding and testing the solutions.
 They are the most likely stakeholders you will rely on to get development
estimates.
 Developers are among those with the deepest technical knowledge, yet may
lack the amount of business acumen held by the business and domain experts.
Because of this, be sure to engage them as stakeholders who determine
feasibility of a solution rather than the cost effectiveness of it.
152
Types of Stakeholders – End Users
 The end user is the consumer of the product. They are not the customer.
 Among the most important factors this stakeholder brings to the project is the
revenue that the business wants to gain.
 The end user’s expectation is that the delivered product performs as it was
intended.
 You are working to please the end user, not the customer. The customer is your
advocate to help translate what the end user wants. The end user will then tell
you if what is delivered does what it was expected to do.
153
2. Stakeholder Involvement
Recall that Agile maintains and expects a high degree of stakeholder involvement
throughout the value stream. This gives more visibility in the project than non-
Agile disciplines provide.
 Stakeholder involvement throughout the project yields a higher degree of

assurance that the product will live up to expectations.
 Continuous stakeholder involvement ensures that the project will stay aligned
with its chartered purpose.
The following pages detail information, techniques and tools used to ensure
stakeholder involvement. Included are:
• Key factors that affect stakeholder involvement
• The Participatory Decision Making Model
• How to effectively use documentation while communicating to stakeholders, and
how to avoid documentation pitfalls.
© BetterPM.com 154
Factors Affecting Stakeholder Involvement
There are a number of factors that impact the engagement style and participation on the
project. As you work to serve as facilitator of participation, it’s important to identify how
stakeholders participate with a solution delivery team.
Factor Range Potential Impacts
Participation Reactive Proactive • Stakeholders who are highly proactive participants with the
Style team might possibly have an agenda that could threaten the
project
• Stakeholders can tend to derail the project if they ask
tangential questions and slow down the team
• Reactive stakeholders may signify that there’s a negative
relationship between parties that goes beyond this project.
Relationship Negative Positive • When the relationship between IT and stakeholders is negative
the stakeholders will likely participate less frequently.
Communication Formal Informal • Formal communication can increase time delays and cause
Channels bureaucracy on the team. Agile always favors in-person
communication and informal communication strategies.
Source: http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm
© BetterPM.com 155
Factors Affecting Stakeholder Involvement
Factor Range Potential Impacts

Availability Irregular Continuous • When stakeholders aren't regularly involved with a project
team (such as missing the retrospective) there’s a larger chance
that the team will face rework and missed requirements.
Interaction Facilitated Active • When interaction with stakeholders needs to be facilitated by a

third person, (such as between team and the stakeholders) you
run the risk of miscommunication and increasing the team's
time to delivery. Remember the game of “Telephone?”
Location Co-located Global • When the team is co-located with stakeholders it is much
easier to achieve consistent communication. As the team
becomes more geographically distributed, the chances of
project success decrease. It must be noted, however, that the
use of global, distributed teams in agile is still acceptable.
Source: http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm
© BetterPM.com 156
Participatory Decision Making
Involved stakeholders are active participants in helping make decisions about the
project. The leader must think of the best possible style that will allow the
organization to achieve the best results. According to psychologist Abraham
Maslow, workers need to feel a sense of belonging to an organization.
The important thing to remember

about practicing PDM is to make your
team feel important to the project.
PDM can be used in:
PDM is also known by these terms:
• Team retrospectives
• Shared Leadership • Stand-ups
• Employee Empowerment • Customer demos
• Employee Involvement
• Dispersed Leadership
• Open-book Management
• Industrial democracy
© BetterPM.com 157
Documentation - An Agile Business Case
Wait – documentation on an Agile project? Really?
Although Agile favors the elimination of waste and unnecessary documentation, it
would be incorrect to suggest that no documentation at all occur.
As mentioned earlier in this chapter, your customer’s involvement in the project

as a stakeholder includes the creation of a business case. The business case is
meant to generate buy-in from your organization and gain the support of an
influential project sponsor.
 The business case justifies the reason for the establishing the project.
 It includes cost and value justifications, such as ROI.
 The business case will speak to each business stakeholder in a variety of ways.
For instance, making a case to strengthen the product portfolio – and
therefore the business’s core offerings.
 Items such as resourcing and risks should also be covered.
© BetterPM.com 158
Documentation - Agile Charters
Another tool that is necessary to ensure the delivery of value to the stakeholder is
the project charter. The project charter is typically much more lightweight than it
might be in other disciplines, but the charter is still a valuable tool in agile.
Things to include in an agile charter

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.
An agile project charter should also include a Project Overview Document, Which
we cover on the next page.
© BetterPM.com 159
Documentation - Project Overview
The Project overview document is a summary of critical information such as:
 The vision for the system
 Primary user contacts, technologies and tools used to build the system
 The critical operating processes (some applicable to development, such as how
to build the system and some applicable to production.
 References to critical project artifacts such as the source code and where
other documents are.
The project overview

document goes by many
different names in
different organizations. It
is not a key PMI term.
© BetterPM.com 160
Documentation - Progress Reports
Although Agile and Lean concepts recommend eliminating waste, an essential
part of stakeholder involvement is the progress report.
An Information Radiator is a large display of critical team information located in a
spot where people can see it as they work or walk by. A good information radiator:
• Is large and easily visible to the casual observer
• Changes over time
• Is understood at a glance
• Is easily kept up to date.
Examples of information radiators include

customer demos, the vision statement,
release and iteration plans, and burn-up
charts. A burn-up chart (right) tells how
much work the project contains and how
much scope has increased at each
iteration.
© BetterPM.com 161
Documentation - Product Roadmap
 The product roadmap is an overall view of the product's requirements and a
valuable tool for planning and organizing the journey of product development.
 Created by the product owner with help from the development team.
 The roadmap is used to categorize requirements, to prioritize them, and to
determine a timetable for their release.
 Your product roadmap can be as simple as sticky notes arranged on a white
board
© BetterPM.com 162
Documentation Traps to Avoid
Documentation is considered to be a less effective means of communication than
in-person communication. Although Agile doesn’t entirely eschew documentation,
there’s a certain level that is considered wasteful in an agile project. The
important thing to keep in mind is to create reports that add benefit, not measure
unnecessary statistics.
Avoid these types of documents
Velocity Reports across teams – You should deliver
Remember that Agile
velocity reports, but not measure velocity across
promotes the minimizing
teams because each team creates estimates
of waste. You should
differently.
document the project,
Quantitative reports – Lines of code and number of
but do not over-
stories should not be tracked as individual reports.
document.
Speculative concepts – You should document stable,
specific concepts versus what-ifs.
So, what should you document?
• Information that is owned by a single source
• System overview documents
• Executable specifications
© BetterPM.com 163
3. Stakeholder Expectation
Managing stakeholder expectations is likely the single most important role for any
project manager.
Agile projects offer some unique challenges as well as advantages:

 We need buy-in for the iterative/incremental build approach.
 We need support for the ongoing business involvement, we need trust in
letting teams self organize and pull work from the prioritized backlog.
These items need explaining and approving with sponsors and business
representatives.
In addition, the team also needs to know what is expected of them, undertaking a
variety of roles, often without complete information and likely to iterate to the
true requirements.
© BetterPM.com 164
Waterfall and Agile Approaches to Stakeholder
Management
 Although both Waterfall and Agile expect a high level of involvement and
communication with stakeholders, there are some key differences.
Waterfall Agile
Stakeholder Roles Categorized according to four Categorized according to
levels using a RACI Chart: potential impact to the
Responsible, Accountable, project.
Consulted, Informed
Involvement More communicative than Requires continuous
Style collaborative communication and
involvement
Awareness of Most stakeholders have an Stakeholders will need to be
development understanding their expected role “sold” on the benefits of Agile
model in a waterfall project. if it is newly introduced to a
company.
Reference: “It’s the Business, Stupid!” http://www.scrumalliance.org/articles/79
© BetterPM.com 165
Ten Principles of Stakeholder Management
As you manage communication and collaboration with your stakeholders, keep in
mind these principles that must be kept in mind when managing them during the
project.
1. Stakeholder interests need to go together over time.

2. We need a philosophy of volunteerism – to engage stakeholders and manage
relationships ourselves rather than leave it to government.
3. We need to find solutions to issues that satisfy multiple stakeholders
simultaneously.
4. Everything that we do serves stakeholders. We never trade off the interests of
one versus the other continuously over time.
5. We act with purpose that fulfills our commitment to stakeholders. We act
with aspiration towards fulfilling our dreams and theirs.
6. We need intensive communication and dialogue with stakeholders – not just
those who are friendly.
© BetterPM.com 166
Ten Principles of Stakeholder Management
7. Stakeholders consist of real people with names and faces and children. They
are complex.
8. We need to generalize the marketing approach.
9. We engage with both primary and secondary stakeholders.
10. We constantly monitor and redesign processes to make them better serve our
stakeholders.
Citation: Managing for Stakeholders

Authors: R. Edward Freeman, Jeffrey S. Harrison, Andrew C. Wicks
Publisher: Yale University Press (October 30, 2007)
ISBN-10: 0300125283
ISBN-13: 978-0300125283
© BetterPM.com 167
 Which of the following is not an aspect of stakeholder management in an agile
project?
•Stakeholders are expected to attend the daily standups
•The stakeholders may need to be "sold" on the benefits of Agile.
•Stakeholders are categorized according to their level of impact to the project
•Stakeholders are expected to have a continuous level of involvement and
collaboration in every phase of the project.
What is a burn-up chart?
•A graphical chart that shows how much work and scope have been accomplished over
time on the project.
•A chart that shows which risks have risen to issues on the project.
•A graphical chart that shows how much work the project contains and how much
scope has been added at each iteration.
•A graphical view of all work to be prioritized and estimated following the gathering of
user stories.
© BetterPM.com
 Which of the following is not considered a type of participatory decision
making?
•Employee involvement
•Shared leadership
•Industrial democracy
•Centralized leadership
What is a potential impact of overly formal communication methods on a
project?
•Stakeholders who are proactive personalities risk becoming aggressive.
•Negative relationships between parties
•Time delays and bureaucracy
•Unnecessary additions to the burn-down chart
© BetterPM.com
Module 5: Boosting Team Performance Practices

Module Overview
This module focuses on the PMI-ACP exam’s Team Performance knowledge
domain, which focuses on
In this module:
1. Team formation
2. Team empowerment
3. Team collaboration
4. Team commitment
© BetterPM.com 171
Module Objectives
 Facilitate the team in collectively creating ground rules and internal processes
in order to remove fear of conflict and strengthen members’ commitment to
shared outcomes
 Help form cross-functional teams by ensuring all skills and resources necessary
are readily available in order to enable the team to deliver on their
commitment.
 Identify team members that have the right combination of soft and technical
skills and encourage them to be generalizing specialists in order to maximize
teamwork and reduce bottlenecks.
 Ensure the team has a common understanding of the values and principles of
agile and a common knowledge around the agile practices and terminology
being used.
© BetterPM.com 172
 Empower the team to self-organize around the work in order to manage the
project’s complexity and produce effective solutions.
 Create a safe team environment by allowing people to experiment and make
reasonable mistakes so that they learn and continually improve the way they
work.
 Continuously discover team and personal motivators and de-motivators in
order to ensure that the team remains motivated and productive throughout
the project.
 Establish collaborative behaviors among the members of the entire project
team by applying group decision making and conflict resolution techniques in
order for them to take responsibility for outcomes and improve their
effectiveness.
© BetterPM.com 173
 Facilitate close communication within the team and with necessary

stakeholders through colocation or collaborative tools in order to reduce the
cost of miscommunication and rework.
 Facilitate commitment by protecting the team from outside distractions in
order to establish a predictable outcome and optimize the value delivered.
 Align project and team goals by sharing project vision and aligning team
objectives with project objectives in order to ensure the team understands
how their objectives fit into the overall goals of the project.
 Encourage the team to measure its capacity by tracking and measuring actual
deliverables in previous cycles in order for members to gain a better
understanding of their velocity and commitment.
© BetterPM.com 174
1. Team Formation
A high-performing agile team relies on the strengths of the individual, cross
functional contributors to function as a self-empowered, decision-making team.
Although this may cause overlap with traditional forms of management, normal
corporate roles should not influence team formation.
Product Management
Team
Product Owner
Team
Architecture Working System
Team Produced
SMEs/DBAs/Developers
Supporting Cast
(integrator, testers, domain experts)
© BetterPM.com 175
High Performance Team Characteristics:
Definition of Done
 A high performance team:
1. Identifies measurable tasks….
2. …that have clear prioritization…
3. …that achieve team agreement.
 This is the Definition of Done. Many Levels = Many DoDs

The Definition of Done (DoD) is a simple Feature: Story or product backlog
list of activities that add verifiable and item
demonstrable value to the product.
Sprint: Collection of features
developed in the sprint
Release: Potentially shippable state
© BetterPM.com 176
Using the Definition of Done in the Team
There are various factors which influence whether a given activity belongs in the
DoD for a feature, a sprint or a release.
For activities that cannot be included for a sprint/feature, teams should, discuss
all of the obstacles that stop them from delivering each iteration or sprint
Common root causes for impediments include:
 Team does not have the skillset to incorporate activities into the definition of
done for a sprint or for a feature.
 Team does not have the right set of tools. (Example: continuous integration
environment, automated build, servers etc.)
 Team members are executing their sprint in mini-waterfalls.
© BetterPM.com 177
Definition of Done – Key Characteristics
 The DoD is a checklist of value-based activities to produce the software or
system.
• This allows focus to be placed on value-added steps and to eliminate waste
 The DoD is the primary reporting mechanism for team members.
• In it’s simplest form, it’s the ability to say, “this feature is done.”
 The DoD is an auditable checklist
• It validates whether all major tasks are accounted for.
 The DoD is not static
• Organizational support and the team’s ability to remove obstacles should allow the
DOD to evolve.
 The DoD is informed in reality
• The goal is to produce “potentially shippable software”
Reference: http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod
© BetterPM.com 178
High Performance Team Characteristics:
Measurable Competence
 A high performance team is cross functional but at the same time
has specific levels of competence and expertise to minimize power
struggles.
 The agile team has role clarity with an expectation for each member
to meet or exceed their expected competency level to complete
their tasks.
 For example: The agile project manager keeps an eye on the product
backlog and protects the team from changes once the iteration has
begun.
© BetterPM.com 179
The Distributed Team Model
Agile favors face-to-face, in person communication. When that can’t happen, such
as when business partners or outsourcing are used, Agile acknowledges that there
are still benefits to be gained as a disparate team.
Agile teams can operate within the concept of the Distributed Team Model. In the
years leading up to the Agile Manifesto, it was expected that teams remain small
and be placed in one room. But Agile has evolved to expect and support large
teams in a distributed model.
In a distributed model:
 Teams see each other infrequently or not at all.
• Sometimes known as “Virtual Teams.”
• Tools such as Planning Poker and the Participatory Decision Making are invaluable
as mechanisms to ensure the distributed team members still have an equal voice.
 Team members may be on different floors or in different countries and time
zones, such as with offshore teams.
 Teams may be larger than the traditional size of an agile team.
© BetterPM.com 180
The Strengths and Weaknesses of a Team
Agile teams do not operate without risks. A core concern is to continually ensure
that all team members have a voice in the project and are not dominated by one
person. And yet, the need to be democratic can lead to wasted time if not kept in
check by the agile project manager.
Positives Negatives
Enables creative problem One team member may begin
solving to dominate
Scalable Can lead to unnecessary
meetings just to be democratic
A wide range of skill levels and Egos are in play
ideas
Empowered to evolve the DoD Time may be wasted with
as solutions are found talking instead of working.
© BetterPM.com 181
Risks to Team Success
It is possible for an agile team to be established under the best of intentions and
operational climate yet still fail to achieve success. The following are the key risks
to success:
 High geographic distribution leads to environmental differences
• Electronic tools such as electronic documentation and instant messaging should be
supplemented by a physical meeting space or “war room” that still promotes the
concept of a group.
 Lack of clear goal setting
• If goals are unclear or are under-communicated, the team members will perform
their tasks in the absence of attention toward a common vision. Waste will occur.
• Agile teams must work to ensure that shared decision making and shared
responsibility occur so that team members feel empowered.
 Unclear roles
• Agile teams must include a clear leadership structure, shared responsibility, and an
impatience for power plays or passing the buck.
© BetterPM.com 182
Risks to Team Success (cont’d)
 Poor Communication
• Personality conflicts and competitive relationships threaten to undermine the
success of a team.
• Agile teams must constantly promote open dialog and in-person discussions.
 Failures of process
• One-way, top-down or unspoken communication channels will disrupt the success
of the team.
• Well structured standups that enable each member to report on their
accomplishments and concerns is a core tenet of the agile framework.
• Agile teams must include a clear leadership structure, shared responsibility, and an
impatience for power plays or passing the buck.
© BetterPM.com 183
Tools to Keep the Team Strong – Team Contract
Agile teams use a variety of tools and methods to ensure that the risks of team
dynamics are mitigated.
The Team Contract

Also known as a Working Agreement or
Ground Rules, the contract is a simple
document which can be changed every
iteration or sprint, or whenever
necessary. Anything goes here that all
developers agree on.
© BetterPM.com 184
Tools to Keep the Team Strong – Emotional
Intelligence
 Traditional leadership generally involves the accumulation and exercise of
power by one at the “top of the pyramid.” By comparison, the servant-leader
shares power, puts the needs of others first and helps people develop and
perform as highly as possible.
 Emotional intelligence is the ability to identify, assess, perceive, control, and
evaluate emotions.
 Servant Leadership was coined by Robert K Greenleaf in The Servant as
Leader, an essay first published in 1970.
• “The servant-leader is servant first… It begins with the natural feeling that one
wants to serve, to serve first. Then conscious choice brings one to aspire to lead.”
• The servant leadership style is an excellent concept for the agile practitioner to
follow. You are expected to balance yourself between being a contributor and a
collaborator, between short-term goals and long-term goals of the project.
• The following slide shows the variety of functions you perform as a servant leader.
© BetterPM.com 185
Characteristics of Servant Leadership
Conceptualization
Building
Community
Listening
Stewardship
Healing
Healing Persuasion
Guru/subject
Awaeness
matter expert
Commitment to
the growth of Awareness Foresight
people
© BetterPM.com 186
Things to remember as a Servant Leader
 Place yourself in the role of between a contributor, collaborator and leader.
 Don’t focus on just the strategic and tactical aspects of the work – you also
must act as a coach and advocate for the team. Monitor the dynamics of the
team.
 Focus on the work as well as the team’s health.
For the Exam

Be aware of questions that test for your
knowledge of the importance of “team.”
Being an agile practitioner means that you

are working to keep the team healthy and
productive, and you’re not focusing
squarely on any one thing – be it tactical,
strategic, or self-fulfilling items.
© BetterPM.com 187
Growing as a Team Member
There are many ways in which you can grow as a team member yet continue to
fulfill the role of servant leader for the team as a whole. It’s important for each
member on the team to grow as an individual, which will then make the team
stronger.
 Affirm your strengths.
• If you’re a good problem solver, or a good questioner, leverage this as a positive
addition to the team. Not every member has the same strengths, so each person
should use this to their advantage.
 Avoid situations where your strengths are not valued.
• Remember that a core principle of agile is to add value and eliminate waste.
▫ If you are expected to be a problem solver on the team, be sure to place yourself in
situations where problems are waiting for your help.
▫ If you are a subject matter expert in a particular area, make sure you are able to focus on
those deliverables rather than be placed in other work streams.
© BetterPM.com 188
Growing as a Team Member (cont’d)
 Be an observer of the team
• Is there a particular strength still needed on the team? Would the team benefit
from a new idea that can only be seen from the macro level?
 Improve upon your weaknesses by drawing on the strengths of others.
• If you’re a poor communicator, watch the strong communicators on the team and
focus on learning their skills.
For the Exam
The exam expects you to show your knowledge

of teams as being cohesive units that
democratically work toward a common goal
with little distraction in achieving it.
The exam does not expect the team members to
be so homogenous that there’s no individual
distinction, and yet it also expects you to know
that rising ego or conflict due to the
overpowering of others.
© BetterPM.com 189
Team Trust
 Agile principles require that you build projects around motivated individuals.
Give them the environment and support they need to get the job done, and
trust in them that they can achieve their tasks.
 Trust is a core tenet of Agile. Once trust is broken, it is not easily recovered.
• Trust allows the team to stay problem-focused, it promotes efficient
communication, and it improves the quality of collaborative outcomes.
 Trust has four core elements:
Element Description
Honesty The team member acts with integrity and upholds
core values.
Openness Open to share, learn new things, consider
alternate approaches
Consistency Behavior and reactions that come to be expected.
Respect Treat people with the dignity and fairness that

would be expected in return.
© BetterPM.com 190
From Forming to Performing
Agile makes use of teambuilding concepts based on the Tuckman model, popularized in the
1960s by Bruce Tuckman, a pioneer in the research of group dynamics. Tuckman’s model
posits that as time advances, a small group gradually matures by moving through common
stages as they grow and begin to tackle increasingly complex problems and ultimately
deliver strong results as a cohesive team.
We will review each stage in the Performing

following slides.
Norming
Storming
Forming
Reference: Tuckman, Bruce: “Developmental Sequence in Small Groups”

Psychological Bulletin, 63, 384-399 (1965)
© BetterPM.com 191
Team Development - Forming
What it looks like
 When the team is in the forming stage, the group members are waiting for
leadership and they may still be very formal with each other.
 Goals and vision are not yet established.
 The team members are unclear of their role.
How you can help

 Facilitate the team to begin writing its charter or mission statements, and buy-
in starts to get established.
 Get the team to perform tasks that will allow them to get to know each other.
 Begin to empower the team to set expectations and boundaries.
 Begin to communicate and reassure.
© BetterPM.com 192
Team Development - Storming
What it looks like
 The team members are ready to get moving on the project
 Personalities emerge. Strengths, egos, and conflicts begin to appear
 Some members may sit on the sideline as stronger personalities take over, or
as conflicts emerge
How you can help

 Communicate openly and with no surprises
 Participate in all meetings and value diversity
 Acknowledge others’ strengths and accomplishments to defuse any conflicts
 Start to play the role of supporter and advocate
© BetterPM.com 193
Team Development - Norming
What it looks like
 Team members begin to see how they are alike
 A sense of team takes hold, and they realize that they are “all in this together.”
 Social walls break down and communication begins to occur
• If this goes too far, they may forget the true reason they are together – not to have
a good time, but to tackle a task.
How you can help

 Acknowledge that the team is similar with like characteristics
 Train people as necessary to keep the team consistent
 Keep the team focused on the goal
 Encourage the team members to get comfortable with each other
© BetterPM.com 194
Team Development – Performing
What it looks like
 The team members are trained, have a clear vision, and are ready to get
started.
 The leader will begin to challenge the team and begin to develop them further.
 The team will begin to expect more from you in terms of processes and rules.
How you can help

 Acknowledge the efforts of each
team member. Interesting Note: a 5th Phase
 Give new challenges to them In 1977, Tuckman added a fifth stage to his
model and called it Adjourning.
 Encourage continued growth.
The idea behind adjourning is that a closure
• Remember that the Definition of process is acknowledged in which the team
Done will evolve as the team gets completes their tasks and moves on.
stronger. This is your opportunity to
help make that happen. The Sprint Retrospective has many parallels to
adjourning.
© BetterPM.com 195
Review: Characteristics of a High Performing
Team
Teams can succeed on a project where one person cannot. A high performing
team requires the ability to build a strong team with individuals who are able to
interact well with each other. The following are key characteristics of the agile
team:
 Able to work in close proximity or as a distributed group.
 Favors low-tech communication tools over complicated systems.
• In-person communication is always preferred.
 Competent members of from a cross section of knowledge domains.
 A climate of collaboration
 Creates a framework yields an agreement on the Definition of Done.
 A clear goal to achieve results-driven value and minimize waste.
© BetterPM.com 196
2. Team Empowerment
Not only are agile teams highly cross functional and with a strong set of
competencies, they also operate with a high degree of empowerment.
 The team is responsible to establish a framework that permits them to

perform their work with the primary objective being to find solutions.
• Teams of highly skilled individuals that are cross functional with high competency
are still apt to fail if they cannot be permitted to rapidly solve problems within
their own guidelines and rules.
 The team decides on their Definition of Done for the tasks, feature or project.
© BetterPM.com 197
3. Team Collaboration
Agile encourages close customer communication and collaboration. Typically, the
customer is represented in the design and requirements documents. But for
communication with the team that involves live communication (a core tenet of
agile), documentation is less significant on the project compared to team
meetings. These meetings are essential to team collaboration on an agile project:
 Release Planning Meeting

 Iteration Planning Meeting Remember the Manifesto
 Daily Standup Meeting “Individuals and interactions over
 Review/Demo Meeting process and tools.”
 Retrospective Meeting “Customer collaboration over

contract negotiation.”
© BetterPM.com 198
Release Planning Meeting
The Release planning meeting is used to produce a high-level release plan with
delivery dates, number of iterations and the primary stories that will be delivered.
Initial release planning meetings rarely last longer than a day (sometimes two
half-days.)
Release Planning
Inputs Meeting Outputs
 The customer presents the prioritized features to be delivered.

 Features and themes are reviewed and prioritized. Ideally, the developers have
already devised rough estimates of how much work is required to implement
each of those features.
 The team determines which features are delivered within the timeframe
identified.
• Velocity (both prior or estimated) is used to determine this. Velocity will be
covered in an upcoming module of this course.
© BetterPM.com 199
Release Planning Meeting Outputs
The Release planning meeting is to produces a high-level release plan with
delivery dates, number of iterations and the primary stories that will be delivered.
Initial release planning meetings rarely last longer than a day (sometimes two
half-days.)
Release Planning
 The Preliminary Release Plan is created.

• Although it rarely satisfies all parties (not enough functionality vs. too much time,)
the teams looks at the hard truths and plans around them.
• The plan is understood to be rough. It is enough to get the team started.
 Key dates and milestones are established
 Iteration 0
• Many teams arrive at an “iteration 0” which allows the opportunity to work
through technical and logistical issues.
© BetterPM.com 200
Release Planning FAQs
Release Planning
 How long is a release?

• Releases typically range from 2 to 12 months. For longer releases, it may make
sense to break it down into smaller releases.
 How many iterations are in a release?
• The number of iterations within a release is typically driven by the schedule. If a
release is 6 months long, and iterations are 2 weeks, then 13 iterations should be
scheduled for the release.
 Who participates in the release planning meeting?
• For small teams, it’s acceptable for the entire team to attend.
• For large teams, it’s recommended that a cross section of representatives attend.
© BetterPM.com 201
Iteration (Sprint) Planning Meeting
The agile software development team holds a planning meeting at the beginning
of each iteration to identify the stories that will be developed, and to break each
of them down into specific technical tasks and acceptance criteria.
Iteration Planning
 The product owner or product manager presents the stories they are
considering for the iteration to the team.
 Each story is discussed to clarify its meaning and scope. Larger stories are
broken down and estimated as necessary.
 Existing story estimates may be adjusted if during story clarification, new
information comes to light that changes them significantly.
© BetterPM.com 202
Iteration Planning Meeting Outputs
The agile software development team holds a planning meeting at the beginning
of each iteration to identify the stories that will be developed, and to break each
of them down into specific technical tasks and acceptance criteria.
Iteration Planning
 The team takes the candidate iteration backlog and breaks it down into lower
level execution details.
 The design of the items in the iteration backlog is extended by decomposing
the stories into tasks and clearly-defined acceptance criteria.
 The team estimates each task, typically in hours or ideal days.
 Once this decomposition analysis and design is complete, team members
confirm that the estimates they have identified do not exceed the team’s
anticipated availability/capacity for the iteration.
 The team can then commit to the iteration backlog and the iteration begins
© BetterPM.com 203
Iteration Planning FAQs
 How do you handle dependencies between tasks?
• As part of iteration planning, the team should strive to minimize task dependencies
as they divide features up. Agile teams embrace simple, adaptable designs that are
lightly coupled to minimize dependencies. The teams are empowered to work
vertically to build what they need.
• Whereas traditional project management practitioners may expect to see items
such as Gantt charts, Critical Path Method data and complex estimation charts,
agile practitioners empower the teams to wait for dependencies to be completed*
and raise issues in the daily standup if the dependency resides in the backlog.
 How much should a team member sign up for?
• A team member should rarely sign up for more than the total estimate of the tasks
they were able to complete in the prior iteration.
 How do you plan iteration if the team size varies?
• With iterative development, there is typically some history that is built up over
time to use as a basis for planning. If you team is cut in half, then a simple
calculation should lead you to plan no more than ½ of the original ideal days for the
upcoming iteration.
* Reference: http://www.agilecoachjournal.com/index.php/2012-04-26/teams/managing-technical-dependencies/
© BetterPM.com 204
Iteration Planning FAQs (Cont’d)
 How do you account for overhead such as email, meetings, etc?
• Teams generally do not spend much time tracking minor overhead items. Over the
course of a few iterations, these interruptions become a constant amount of
predicable time that can be factored in during planning.
 How do you account for bug fixing during iteration planning?
• One of the simplest is to include bugs as explicit input to iteration planning,
prioritizing it, and estimating the tasks involved. Bugs are essentially equivalent to
features in terms of units of work for planning purposes.
 Why should iterations always be the same length?
• Iterations with the same or very close lengths provide a rhythm that teams rely
upon for estimating and planning. Without fixed-length iterations, it can be difficult
to achieve and measure steady velocity (which is covered in a later module.)
 How do I account for testing and documentation time?
• This should be planned and prioritized just like everything else.
• These items are often created as tasks under specific features, but may also be
grouped as their own feature.
© BetterPM.com 205
Iteration Planning FAQs (Cont’d)
 Should feature estimates be revised during iteration planning?
• Feature estimates should only be revised during iteration planning if the original
estimate is found to be way off base and the new level of effort will have a
significant impact on the team's ability to complete other work
 Should task estimates be revised during an iteration?
• The original task estimate should not be revised once the iteration planning has
been completed.
• However, the estimates for future iterations should be continually revised to reflect
an accurate assessment of remaining work.
 Should all teams operate on the same iteration schedule?
• It is recommend that this occur whenever possible. This allows for the rolling up of
iteration status across teams and measuring velocity across teams.
• A disadvantage of this approach is that some teams may have members that are on
both teams. A staggered approach may give the resource(s) room to breathe.
 What is the duration of the meeting?
• It lasts approximately one hour per week of sprint work planned.
© BetterPM.com 206
Daily Standup Meeting
Agile development processes depend on a high level of communication and
collaboration for success. This is no truer than in the daily standup meeting that
occurs during an iteration.
The Three Questions in a Daily Standup

 What did you do yesterday (or since the last
standup)?
The Daily Standup is
 What will you do today (or before the next known as the Daily
daily standup)? Scrum in eXtreme
Programming (XP)
 What impediments are preventing you from
making progress?
Scrum Master is accountable to the team and must deal with any
impediments as quickly as possible. This may mean scheduling a follow-up
meeting with the necessary people right after the standup.
© BetterPM.com 207
Daily Standup Meeting – Other Characteristics
 Meetings are typically held in the same location and at the same time each
day.
 Ideally, the daily scrum meeting is held in the morning, as it helps set the
context for the coming day's work.
 The daily standup meetings are strictly time-boxed to 15 minutes.
 All team members are required to attend the meeting. Since both the
Scrum Master and Product Owner are committed team members, they are
expected to attend and participate.
 All ancillary stakeholders (such as a departmental VP, a salesperson or a
developer on a different project) may attend but is allowed to only listen,
not speak.
 It’s not a problem-solving session or issue resolution meeting. Issues are
taken offline with the facilitation by the Scrum Master immediately after
the meeting.
© BetterPM.com 208
Daily Standup Meeting – Other Characteristics
 It is not a status-gathering meeting where the boss gleans which team

members are behind schedule. It is instead a meeting where team
members make commitments to each other. Consider:
• Standup Meeting Today: “Today I will finish the Widget X module.”
• Standup Meeting Tomorrow: The team members will expect either a status of
completion, or a identification of an impediment that precluded completion.
 The vast majority of teams conduct the daily Scrum meeting by having each
person answer the three questions in order.
• You answer all three, then the next person, then a third, and so on.
• Some teams find it helpful to talk through one product backlog item before
moving on to the next. In this way, an individual may give an update at multiple
different times during the same meeting.
© BetterPM.com 209
Daily Standup Meeting – Example Impediments
It is the responsibility of the Scrum Master to quickly resolve impediments

either directly, or by engaging other team members to assist. Impediments are
typically handled immediately after the standup meeting.
Example impediments include:
 The 3rd party’s helpdesk has not yet
gotten back to me with an answer.
 I’m having trouble learning this
new software package or
application.
 I can’t get time with the _____
group to answer my questions.
 Our offshore team cannot access
our VPN.
 I can’t debug a particular line of
code.
© BetterPM.com 210
Review/Demo Meeting
The review meeting is an opportunity for the team to demo the results of the
iteration to the customer and the stakeholders. It is generally held on the last day
of the iteration or the first day of the next iteration. This is a great opportunity for
stakeholders not allowed in the standups to get an idea of progress. It’s also an
opportunity to get initial feedback on what has been developed.
 Duration: The review generally lasts approximately one hour per week of
sprint work planned.
 The meeting is open to a wider group than is
allowed in the standup: Invited members include
the customer, team management, stakeholders,
This meeting is also
and the project team.
known as the
 The goal of the review meeting is to successfully “Iteration Review” or
demonstrate the features and functions completed the “Sprint Review.”
during the iteration. Feedback from the
stakeholders is welcome and helps the team
eliminate waste.
© BetterPM.com 211
Review/Demo Meeting – Inputs and Outputs
Iteration Review
 The meeting is started with an accounting of what was originally planned but
not completed. This sets an appropriate expectation for the meeting. The
backlog and the burn-down chart are key pieces of information used.
 User stories that are complete are demonstrated. This meeting is more than a
discussion: it’s an opportunity to demonstrate what’s been built.
 User stories that are not complete are identified with an explanation of why
they are incomplete.
© BetterPM.com 212
Review/Demo Meeting – Inputs and Outputs
Iteration Review
 The stakeholders are given an opportunity to comment on their likes and

dislikes of the features reviewed. This is an opportunity to get an indication if
rework or a major course-correction is necessary on the feature. It also can
serve as a great way to validate if the feature is on track.
 The feedback is used for the planning of the next sprint. Rework on the
features demoed would initially be placed in the backlog for consideration in
the next iteration planning meeting,
 After the review is over, the date for next review is announced and the team
moves to Sprint Retrospective.
© BetterPM.com 213
Retrospective Meeting
Continuous improvement is a fundamental tenet of today’s agile teams.
Retrospectives serve as the opportunity for teams to collaboratively examine and
expose opportunities for improvement in terms of process and practices. It is also
a chance to discuss what went well.
The meeting is a time to discuss issues that affected the team’s overall
effectiveness, productivity and quality as well as the team’s satisfaction with the
project.
 The meeting is time-boxed to last no
more than three hours.
Just like iteration planning and
 If the team did not complete all of the release planning, retrospectives
user stories in the iteration, then the take place in a regular rhythm.
agile coach will discuss what and why Many of the more effective agile
it happened. teams conduct retrospectives at
the conclusion of every
iteration.
© BetterPM.com 214
Retrospective Meeting – Inputs and Outputs
Retrospective
 During a retrospective, specific impediments, action items and/or stories are

identified and prioritized.
 The meeting is facilitated by someone with the experience to ensure
participation by everyone on the team.
Retrospective
 Very often, the highest priority items are scheduled and dealt with in the
following iteration.
 The key benefits agile teams get from holding regular retrospectives include
improved quality, team capability, improved throughput and higher trust and
morale. Things could improve so well that definition of done changes.
© BetterPM.com 215
4. Team Commitment
In an agile project, the people who are closest to the work (and who are
completing the work) are the best to know how much time is required to
accomplish it.
The agile framework works because the team and the product owner form a
communication channel that enables this commitment to occur. Anything that
goes against this commitment-based discipline should be removed.
Recall that the team members are given empowerment. This means that the team
is left alone to create their charter and meet their target. They are expected to
have the commitment needed to achieve their goal, however they are permitted
to reach out to management when they need assistance.
© BetterPM.com 216
Leadership Techniques for Team Commitment
The agile practitioner evolves his team from the perspective of:
Teaching Coaching Advising
 Teaching: Showing the student of Agile the rules to buy into the process and help them
conclude on their own that “Agile is better.”
 Coaching: Helping the team member take what they have learned and use it on a daily
basis as part of their operational approach and way of thinking.
 Advising: Your goal is to be able to step away from your role of teacher or coach once
the team has become precisely what agile desires: a self-empowered team that needs
only occasional assistance or advising. You want to “teach the team to fish.”
This concept mirrors that of the Aikodo “Shu Ha Ri,” which guides a person from a stage of
innocence to sophistication to alertness/spontaneity. It means that you “First learn, then
detach, and then transcend.”
Reference: The Meaning of Shuhari, November 2008.
http:/www.shuhari.com/site/view/ShuharisMeaning.pml
© BetterPM.com 217
 Which of the following is not considered a type of participatory decision
making?
•Employee involvement
•Shared leadership
•Industrial democracy
•Centralized leadership
What is a potential impact of overly formal communication methods on a
project?
•Stakeholders who are proactive personalities risk becoming aggressive.
•Negative relationships between parties
•Time delays and bureaucracy
•Unnecessary additions to the burn-down chart
© BetterPM.com
Module 6: Adaptive Planning

Module Overview
This module focuses on the PMI-ACP exam’s Adaptive Planning knowledge
domain.
In this module:
1. Levels of Planning
2. Adaptation
3. Estimation
4. Velocity/Throughput/Cycle Time
5. Designing during Adaptive Planning
© BetterPM.com 220
Module Objectives
 Plan at multiple levels (strategic, release, iteration, daily, etc.) creating

appropriate detail using rolling wave planning and progressive elaboration to
support the necessary level of understanding.
 Engage the team and customer in planning activities to create practical plans
that balance priorities and team capabilities in order to gain increased levels of
commitment.
 Make specific commitments to project sponsors and manage expectations
around those commitments based on actual project experience in order to set
and manage sponsor expectations.
 Coach the team to adjust the cadence and the planning process based on
project characteristics and/or the size/complexity/criticality of the project
deliverables.
© BetterPM.com 221
 Inspect and adapt the project plan to reflect changes in requirements,

schedule, budget, and shifting priorities based on team learning, delivery
experience, feedback, and defects in order to maximize business value
delivered.
 Encourage the team to create estimates that reflect current understanding of
the effort to deliver the project by including all the aspects of delivery
(analysis, development, test, refactoring, deployment preparation, etc.).
 Refine estimate ranges so that they reflect the current level of uncertainty and
the team’s own ability and skills in order to manage stakeholder expectations
© BetterPM.com 222
 Capture a measure of the accepted work completed in a given time frame in

order to gauge progress and extrapolate completion.
 Adjust planning capacity by considering maintenance and operations demand
to ensure team does not over commit
© BetterPM.com 223
Adaptive Planning
Recall that adaptive planning is a major tenet of Agile, which contrasts with the
predictive approach of Waterfall. This module will show how planning, design and
documentation can occur in the agile framework yet still be adaptive by nature.
Mindset Approach
Predictive Waterfall
Adaptive Agile
© BetterPM.com 224
1. Levels of Planning
Agile software development typically consists of five levels of planning which we
will cover in detail in the following slides.
In plan-driven and waterfall methodologies, planning involves large upfront

design, aiming to predict accurately how much work is involved in each project
activity. Dependencies, full work estimates, and detailed requirements are built.
This effort leads to a large investment early in the project, and yet it is by no
means certain that the designed functionality will be delivered exactly as
expected. Change and rework is therefore expensive.
Any agile approach to large-scale developments has to avoid the above concepts
of waterfall or the reintroduction of the Big Design/Requirements Up Front
(covered in module 3.)
One solution to large-scale agile projects is to add planning levels to incorporate a

view of the whole picture.
© BetterPM.com 225
The Five Levels of Planning
Level What it is Frequency Who
Vision Statement 1x-2x/year Product Owner and Executives

Portfolio
Product evolution 1x-2x/year Product Owner and Executives

Product
Roadmap
over Time
Features/User 3x-4x/year Team, Product Owner,

Release
Stories Stakeholders
© BetterPM.com 226
The Five Levels of Planning
Level What it is Frequency Who
Features (user Every Iteration Team and Product Owner

Iteration Stores and tasks)
Tasks, Every day The team

Burndown/to-do
Day items
Release
© BetterPM.com 227
The Agile Planning Onion
 These levels are sometimes referred to as the Planning Onion.
 Agile teams plan at least at the Release, Iteration and Day levels.
 Some organizations may depict a 6th “skin” of the onion representing strategy
Portfolio
Product Roadmap
Release
Iteration
Day
© BetterPM.com 228
The Law of Diminishing Returns
 In Agile, you’ll often hear, “don’t do significant up-front design work.” In
Waterfall, you’ll be expected to do so.
 The agile manifesto says that "Continuous attention to technical excellence and
good design enhances agility." It doesn't say no design or documentation
before you build. So how do you know how much is considered enough
design? Consider the law of diminishing returns, which makes it clear to stop
once the effort trumps the return.
Returns
In general, you can keep developing after a

certain point, but after the quick wins are done
take a moment to evaluate what to do next.
Effort/Time
© BetterPM.com 229
Just Barely Good Enough
As you continue the course, you’ll notice a few terms that act as good Mnemonics
not only for the exam but as terms you’ll treat as vernacular in your day-to-day
work in Agile.
In this module we’ll discuss
JBGE - Just Barely Good Enough
LRM: Last Responsible Moment.
Just Barely Good Enough (JBGE) is a concept from Agile Modeling that states that work
should involve a sufficient level of quality and performance but no more.
In the preceding image of the law of diminishing returns, the ratio of value over time
begins to wane. Rather than continuing to develop additional product enhancements, JBGE
suggests that once the customer confirms acceptance of the feature, additional work
would be wasteful.
Although JBGE occurs during sprints (the build portion,) the decision to not develop
additional items of a feature is a result of the JBGE data points when performing
subsequent iteration planning.
Reference: http://www.agilemodeling.com/essays/barelyGoodEnough.html
© BetterPM.com 230
The Last Responsible Moment
The “Last Responsible Moment” is the point in the planning stages where the
benefits of delaying a decision outweigh the costs of delaying a decision. Your
plan is responsibly deferred, and therefore the more flexibility you have in your
plan. Some things to consider:
• The typical waterfall planning of dates, durations and tasks in “ideal time” as
eschewed by this principle which accepts that uncertainty and change will always
be with the project. Therefore, it’s okay to “responsibly defer” your planning as
you iterate.
• You benefit from avoiding the waste that would have otherwise been created
from unused plans.
• In this methodology, you identify multiple options, but do not defer critical
decisions that would result in scheduling conflicts.
• Use planning horizons to only plan out as far as the project allows you to see.
• The last responsible moment doesn’t necessarily tell you to not decide things
early, it just tells you to avoid over-planning items that may be subject to change
anyway.
For further reading: Defining the Last Responsible Moment by Karl Scotland.
http://availagility.co.uk/2010/04/06/defining-the-last-responsible-moment/
© BetterPM.com 231
How to use JBGE and LRM: Examples
During the build phase, team members should consider the concepts of JBGE as
they develop their features.
For instance:
 Re-coding a feature to take two seconds to communicate to the database instead of
your code’s current three seconds would be wasteful if the customer states that
anything within five seconds is acceptable. But you should perform the re-code if you
know the three second delay would cause larger issues in other features.
 For use of LRM, the scrum master may determine
that the decision whether to recode doesn’t need to
be decided yet, because the follow-on features have Keep in Mind:
JBGE and LRM can only succeed
not been solidified. And it’s not worth wasting time to
if iterative communication with
plan for this event because future releases requiring the customer occurs. A project
it have not yet been determined. using JBGE but that skips review
meetings would risk
misunderstandings of
functionality.
© BetterPM.com 232
Key Features of Adaptive Planning
 Adaptive plans that ebb and flow during development provide better visibility
to stakeholders. How?
• The burn-down chart is transparent to the team members
• The multi-level stage of planning allows for the team and customer to inspect the
development processes and reprioritize any items in the backlog.
• Just remember to display these information radiators and not skip any reviews!
 In adaptive planning , the team takes a committed approach to the
functionality it can deliver at the start of each iteration.
• Stakeholders benefit from the
visibility of knowing that Seem Familiar?
commitments don’t occur until
Many characteristics of successful
the scope has been determined
adaptive planning will remind you
to be achievable in an iteration. of the necessary team dynamics
• This concept requires that covered in module 4:
everyone in the team be truly collaboration, commitment,
committed. empowerment
© BetterPM.com 233
Key Features of Adaptive Planning (cont’d)
 Adaptive Planning requires trust, commitment and collaboration by the team.
• Because the plan is expected to evolve under concepts such as JBGE and JIT, it
requires the team members to understand that the scope and plan is evolutionary
during the project. This may be difficult for the Waterfall practitioner to accept.
• Trust also comes from the product owner and the management in the way of
allowing the team to determine on their own how much it can deliver in an
iteration. The team is expected to be empowered.
• The agile practitioner as Scrum master supports the team by guarding the scope
with the product manager and championing the best practices of agile while
playing the role of servant leader.
© BetterPM.com 234
Impediments to Adaptive Planning
 Assumptions by the stakeholders and
team can emerge which rely on
problems to evolve by “fixing
themselves.” Just because a plan is
structured to be evolutionary does not
mean that it will evolve to a positive
outcome.
• How to mitigate: The team must
continue to trust each other and work
toward the objective of the project.
 Each team member could be at risk of losing focus.

• If the product owner or scrum master doesn’t stay involved, the team loses
visibility.
• If the business owners and/or customers disengage, misunderstandings will form
between the two parties.
© BetterPM.com 235
Impediments to Adaptive Planning (cont’d)
 Organizations that are risk-averse or wary of change
• A high-performing agile team that exists inside a company that isn’t fully
accepting of the agile framework’s fundamentals will eventually become lost and
the team will fail.
• How to mitigate:
▫ The organization and its leadership must adopt the same trust that the agile team
practices.
▫ Long-term vision, priorities and direction must come from the very top of the
organization.
▫ A strong focus on business value will create an environment in which agile practices
can take root.
▫ Create a culture of incremental delivery, the elimination of waste and collaborative
problem solving. If you do these things and communicate your success upward, the
organization will adopt the concepts of adaptive planning and agile even if they don’t
reference them by name.
© BetterPM.com 236
2. Adaptation
Almost the very definition of the word “Agile,” adaptation is a concept embraced
by the agile framework and is one of the primary ways agile projects are kept
from being managed too rigidly. Consider adaptation as being a concept that
allows for looking ahead and course-correcting as necessary, as is explained on
the following pages.
© BetterPM.com 237
Planning Horizons
When setting and revising goals, it is important to remember that we cannot see
past the horizon and that the accuracy of a plan decreases rapidly the further we
attempt to plan beyond where we can see.
Consider the nautical analogy: You’re

standing on a small boat and your eyes are
nine feet above the water. The distance to the
horizon in this case is slightly over four miles.
If you are planning a 20-mile trip, you should
plan on looking ahead at least five times, once
every four miles.
Because you cannot see past the horizon, you need to look up occasionally
and adjust your plan.
© BetterPM.com 238
Planning Horizons
Short Planning Horizons
• Used for detailed, specific plans
• Useful as tools to counter increasing uncertainty surrounding a situation; the
shorter the plan, the shorter the planning horizon, and the more opportunities
for you to “stand up in the boat” and take another look.
Long Planning Horizons
• Used in general planning when there is more certainty and less risk of change.
▫ There will always be uncertainty and a risk of change; set your horizons accordingly!
• The more commitment that’s required, the longer the planning horizon should
be.
© BetterPM.com 239
Rolling Wave Planning
A general rule of estimating is that the more you know about something, the easier it is
to estimate. The less you know, the harder it is to estimate.
It’s important to highlight a key set of tasks and a well-defined work breakdown for the
near-term activities and rely merely on milestones for future work. As the future work
approaches, you break down the milestones into tasks.
Sprint Larger Specific problems Strategic product Strategic product
Work items are
small and well -
functional goals to solve goals line goals
defined.
“Tasky” plans Higher level items and milestones
Now 1 month 3 months 1 year 2 years
© BetterPM.com 240
Progressive Elaboration
Progressive Elaboration occurs in the rolling wave planning process as time
progresses to the larger pieces of scope. Consider the original image after time
has elapsed.
Larger functional goals Strategic product goals
broken down to sprint broken down to specific Strategic product line
items problems to solve goals broken down to
Specific problems to solve product goals, or
broken down to larger product line strategy
Sprint evolves
Complete functional goals
Completed
Work
“Tasky” plans Higher level items and milestones
Now 1 month 3 months 1 year 2 years
© BetterPM.com 241
Continuous Planning
Keep in mind that each cycle feeds the next. The agile practitioner and the
planning team are likely involved in a number of planning and review meetings
concurrently:
Product Road mapping Project Retrospective

Product Road Release Product Retrospective
Mapping
Release Planning Release Retrospective
Iteration Release Retrospective
Release Planning
Iteration Planning Iteration Demos,
Iteration Demos,
Iteration Planning Daily Work Reviews, Retrospective
Reviews, Retrospective
Daily Stand-up
Daily Standup
Task Completion Daily
DailyWork
WorkUpdates
Updates
© BetterPM.com 242
3. Estimation
In agile projects, we accept the fact that project requirements, scope and the
definition of done are subject to change. There’s a certain level of uncertainty that
is accepted as a part of the reality of a project, yet that doesn’t mean that the
agile practitioner doesn’t use tools to improve estimates and get quantifiable
information together for planning purposes.
This section guides you through the techniques used in agile to achieve solid
estimates for the project.
© BetterPM.com 243
Planning from User Stories
Recall from Module 1 that a user story is a key tool used in agile to determine
requirements. It can be as simple as one or more sentences in the everyday or
business language of the end user or user of a system that captures what a user
does or needs to do as part of his or her job function.
Adaptive planning requires the user stories to be

captured so that they can then be broken down into
tasks that can be executed by the team.
Information on a
There are “Three C’s” of user stories:
Story Card:
 Card (shown at right)
 Conversation As a: ________
I want to:______
 Confirmation So that:________
© BetterPM.com 244
Decomposition
Decomposition involves taking the result your user is looking for (stated as a User
Story) and breaking it down into a number of tasks that the team can work on
individually.
Decomposition in Agile takes many forms:

 Feasibility study projects
• When an organization performs a strategic view of their vision, decomposition at
this level leads to separate projects that can then be budgeted. This approach is
counter to the rolling wave style of planning.
 Decomposing strategy into executable projects
• A basic execution sequence consists of Vision, Release Date and Minimum
Marketable Features.
• This approaches the need to decompose user stories into features that will fit into
certain releases.
© BetterPM.com 245
Decomposition (cont’d)
 Decomposing user stories
1. Starting with the three 3 C’s of your user stories (Card, Conversation and
Confirmation,) first place the stories that belong in the current feature of the most
current release.
2. Estimate and prioritize features for the current iteration and the following three
iterations.
3. Create detailed requirements and customer tests for the features in the current
iteration.
© BetterPM.com 246
How to Estimate Velocity
 When estimating velocity, it’s important do to so according to the Definition of
Done.
 Points are used to estimate the relative size of stories.
 Once the points are determined and actuals come in, this information can then
serve as a record of velocity that you can then make future estimates from.
Poker with Points

Module 1 discusses the use of
points as relative values to help
determine the relative size of
stories. The team collaborates on
the estimates through tools such
as Planning Poker.
© BetterPM.com 247
Ideal Time
Consider the typical eight-hour workday: How many hours or productive time do you
get in, on average, between checking your email, multitasking on a separate project,
answering ad hoc questions and phone calls, and other general distractions? In other
words, if you are given an eight-hour task, how can you be assured that you can
accomplish in one workday?
Many agile practitioners use Ideal Time in estimating work. Ideal time is considered
the pure amount of time required to accomplish a task uninterrupted. In a software
project, ideal time would be considered the time spent on programming. In a
discipline such as construction, ideal time would be the time spent building the
structure – but not the time spend reading the blueprints.
In contrast with ideal time is elapsed time. In the example at the start of this slide,
how many hours in elapsed time do you think it would take you to accomplish an
eight-hour ideal time task?
The key is to not mix ideal time and elapsed time estimates on your project.
© BetterPM.com 248
Tools used in Agile Estimation: Point to Scale
Exponential Sequence
Most User Stories will fall here. Represents
Estimations
full functionality that can be accomplished in a sprint.
Recall from Module 1 this
mechanism for estimating user
stories. User stories in future major releases
1 2 3 5 8 13 20 40 100
Epic Level
User stories in current minor releases
Large User Team cannot estimate
Defects, small enhancements, etc.
Stories effectively given current
May or may not need Understanding of work.
to be decomposed Very large user stories that the
further. team can handle but will need to
break down by decomposition.
© BetterPM.com
Tools used in Agile Estimation:
Affinity Estimates
Affinity Estimating is a technique to quickly and easily estimate a large number of
user stories in story points. This is a useful technique if you’re just starting a
project and have a backlog that hasn’t been estimated yet, or in preparation for
release planning.
 Participants include: Medium
Large
Small
• Product Owner
• Delivery Team
• Scrum Master
 How it works
• Stories are be printed on large sticky notes.
• The team presents a set of reference stories the team has done in the past, i.e.
good examples of a point 1, 2, 3, 5, 8, etc. stories.
• Team members are told to silently size each item relative to other items on the
wall.
• The more stories to estimate, the larger the space is needed to do the exercise.
© BetterPM.com 250
Top-Down Estimates
Top Down Estimating is a great way to get meaningful estimates at the start of the
project.
Styles of top-down estimating include:
 Expert Judgment
• Leveraging your domain experts to make an educated guess
 Wideband Delphi Method
• A consensus-based approach using a combination of individual, anonymous
estimates from the team. Forms are used and the sessions are held in multiple
rounds.
 Analogous Estimation
• Uses a similar past project to estimate the duration or cost of your current project,
thus the root of the word: analogy. Not as accurate as other techniques.
 Parametric Estimation
• Determined by identifying the unit cost or duration and the number of units
required for the project or activity. More accurate than analogous estimating.
© BetterPM.com 251
Bottom-Up Estimates
Bottom-Up Estimating is a more analytical method than top-down practice for
estimating user stories. But to achieve a stronger analytical output, a large
amount of inputs are needed:
 Work Breakdown Structure, project plan and schedule
 Customer and user requirements
 Specifications – both functional and technical
© BetterPM.com 252
The Release Backlog
The release backlog is the collection of all story cards that have not yet been
scheduled with a particular iteration.
Backlog items can consist of user stories, features, bugs or anything that remains
to be delivered.
Sprint Backlog
Product Backlog
prioritized by Product Owner
© BetterPM.com
Tools used in Agile Estimation: Iterations
An iteration is a time-boxed set of items that fall under a common category or
theme.
 Iterations are defined in the iteration planning meeting.

 Iterations are completed in the iteration demo and review meeting.
“Iteration” = “Sprint”
© BetterPM.com 254
Other Tools and Devices
 Persona
• A personal is a fictitious person devised to fully represent a user story in planning.
 Feature
• Features are intended behaviors of software or a system that is documented in the
design.
 Task
• The most granular unit of work that is generated from the decomposition of
features. Tasks are generally assigned to one person on the team.
 WIP Queue
• The Work in Progress Queue consists of items such as code to be tested or
documents to be created.
© BetterPM.com 255
4. Velocity/Throughput/Cycle Time
As the saying goes, “if you can’t measure it then you can’t manage it.” Many
useful measurements are used in an agile project to determine its health and
status according to the timeline. In the pages ahead we’ll explore a number of the
ways in which agile projects are measured.
© BetterPM.com 256
Burndown
 Burndown
• Burndown is the rate at which the entire project is eroding (or burning) the
requirements included in the feature list.
• You need to keep the current burndown in mind when making long-term and
release plans.
• Your initial iterations have not yet achieved enough burndown data to allow you to
make accurate estimations of future iterations. By the third or fourth sprint you
should be able to make accurate estimates.
100
90
80
70
60
Effort
50 Series1
Ideal
40 Actual
Series2
30
20
10
0
1 2 3 4 5 6 7 8 9 10 11
Iteration
© BetterPM.com 257
Velocity
 Velocity
• Velocity is tracked on a burndown chart as a depiction of the total task points
remaining per iteration.
• Once the team knows their burndown rate it allows them to determine their ability
to meet their project commitments.
• To calculate velocity, a team first
has to determine how many units Velocity vs. Work Capacity Trend
of work each task is worth and 45
40
the length of each interval. 35
Story Points
30
• During development, the team 25
20
keeps track of completed tasks 15
10
and, at the end of the interval, 5
counts the number of units of 0
20100908
20100915
20100922
20100929
20101006
20101013
20101020
20101027
20101103
20101110
work completed during the
interval. Sprint Name
Velocity Work Capacity
© BetterPM.com 258
Velocity – Key Things to Remember
Objective: Customer satisfaction
Measure: Stories (or story points) delivered; ideal hours delivered. Only
completed items count in this metric
Trend: An upward or stable trend is expected.
When measured: Velocity is a continuous measure.
© BetterPM.com 259
5. Wireframes, Sketches and Prototypes
We all have heard the phrase, “A picture is worth a thousand words,” right? When
understand user stories and ensuring that we are capturing the essence of what
the customer wants, the use of wireframes and prototypes is an effective way to
help the team visualize the solution to be built.
Consider the origin of personal, online

newsfeed and communication software. In
2000, an idea was born by Jack Dorsey for
a service called “twttr.” By 2006 he had a
working sketch and developed an
application using it. His original sketch is
pictured here.
You can see Dorsey’s full explanation of the

genesis of what we now know as Twitter by
reviewing his story at the following
address:
http://www.flickr.com/photos/jackdorsey/182613360/
© BetterPM.com
Wireframes, Sketches and Prototypes
In Agile, the product manager will often not only gather the voice of the customer
but also validate the requirement by presenting a sketch, a wireframe or a
prototype. It generally works like this:
 Immediately after reviewing a user story, the product manager would create
(or enlist a team member) to sketch the story into something visual.
 As soon as the sketch is created and finalized, the product manager would
review the image with the customer and gather feedback.
 An iterative feedback loop develops by which the image can be updated as
necessary until the product manager and customer feel that they have a very
close mockup of the story.
 The product manager then returns to his desk and creates light documentation
(using a wiki or similar tool) to formalize the sketch into something that can be
built by the developer.
© BetterPM.com
What the product manager and team use to visualize the user story can vary.
 Some agile teams will do nothing more than a simple sketch.
 Others will go so far as to create a working prototype to then show the
customer.
 And some teams use the concept of the wireframe to serve as something in
between a simple sketch and a full-blown prototype.
• A wireframe generally looks like a more formal drawing and is more easily editable
than an ink-and-paper image since it’s done with software.
• There are a variety of styles in wireframe tools, but as Agile continues to evolve the
most commonly acceptable format is one of a certain “sketchiness.” On the next
page is an example of a wireframe that uses specific software.
© BetterPM.com
Software-based
Wireframes such as
the one shown here
are common ways to
quickly create
electronic sketches
that can be reviewed
with the customer.
This particular wireframe shows the mockup of a corporate

Intranet using Balsamiq Mockups.
http://www.balsamiq.com/products/mockups
© BetterPM.com
Cycle Time
Story Cycle Time: The number of iterations it takes to complete a story
Cycle Time: The average time between the delivery of completed work items (in
successive deliveries.)
Lead Time: The time between the initiation and delivery of a work item.
Ready for Ready for To be

Backlog In Dev Validating Deployed
Dev Validation Deployed
A common workflow for the typical agile team
© BetterPM.com 264
 A depiction of the total task points remaining per each iteration is known as a
measure of:
•Burndown
•Cycle Time
•Throughput
•Velocity
You are given a report that shows the average time between the delivery of
completed work items in successive deliveries. You are looking at a report on:
•Cycle Time
•Throughput
•Burndown
•Velocity
© BetterPM.com
 You are looking at a story card that has 100 points listed on it. The level that this
task represents is:
•Scope creep
•Minor defect
•Epic Level
•Enhancements level
True or false: When measuring velocity, it is not necessary to know the Definition
of Done:
•True
•False
 A retrospective is occurring one morning, and later in the afternoon the scrum
master will be tied up in a release planning meeting. Is this a problem?
•No, but a separate scrum master should attend one of the meetings.
•Yes, the scrum master should be focused on one iteration at a time.
•No, each cycle feeds the next as part of continuous planning.
•Yes, multitasking on agile projects is a recipe for disaster.
© BetterPM.com
Module 7: Problem Detection and Resolution

Module Overview
This module focuses on the PMI-ACP exam’s Problem Detection and Resolution
knowledge domain, which focuses on how to resolve impediments and mitigate
risks to your projects.
In this module:
1. Creation of a safe, collaborative working environment
2. Key risks to watch for
3. Agile risk management according to PMI
4. Communication Techniques
© BetterPM.com 268
Module Objectives
 Create an open and safe environment to surface problems and impediments

that are slowing the team down or preventing its ability to deliver value.
 Proactively engage the team at various points in the project to identify risks
and create mitigation strategies.
 Ensure impediments are resolved and/or reset expectations in view of
impediments that cannot be resolved.
 Maintain a visible list of risks and impediments in order to elevate
accountability and track ownership and resolution status
 Communicate status of risk and impediments in order to manage the
expectations of the impacted stakeholders.
© BetterPM.com 269
1. Creation of a Safe, Collaborative
Working Environment
As previous modules have suggested, a collaborative environment with open
communication is a key foundational structure for any agile team.
By enabling this safe, collaborate working environment the agile practitioner will have
established the best possible outcome for the identification and mitigation of risks, which
we will explore in the subsequent pages of this section.
The following concepts should be kept in mind when establishing a positive work
environment:
 Your team members are trying to do a good job but may need your facilitation
toward better communication and a clearer direction of their responsibilities.
 Agile promotes the building of team charters and working rules which have a
direct impact on team member performance and the level of risks that arise.
 Confrontation and egos are disruptive to the process, especially during sprints.
You should do everything you can to reduce the chance of this occurring.
© BetterPM.com 270
Conflicts in the Work Environment
Even after all attempts to create this safe, collaborate working environment, conflicts will
arise, which is not unique to agile projects. As an agile practitioner or Scrum Master, it is
your responsibility to set the tone for a principled work environment that supports high
performance from the team. Follow established conflict resolution methods on your
projects.
When conflicts arise:

 Don’t avoid the conflict. You should look for conflicts that are emerging and
you should address them as soon as you become concerned.
 Do not overreact, but make sure you defuse any situation that risks affecting
team performance.
 Play the role of coach, servant leader and intermediary at any time that you
see conflict. As a central figure to the success of the project, you set the tone
for the positive work environment to exist.
© BetterPM.com 271
Conflicts are Impediments
Note that conflicts can lead to impediments.
Your assessment of conflicts requires similar
techniques used in risk mitigation.
Below are examples for ensuring not only a
safe working environment but also one that
enables clearing of impediments:
 Detecting problems is the first step to
resolving them.
 Daily stand-up meetings are an
excellent way to identify any issues
that team members are facing.
 Tools: Teams can also track issues by
calculating cycle times for tasks.
- If the cycle time is too high, it might indicate a potential problem or that the
team has undertaken more work than it can complete.
© BetterPM.com 272
Resolving Conflicts and Impediments with
Risk Mitigation Strategies
Despite our best efforts, some defects may make their way through to the final
product. Escaped defects are the most expensive to fix and are potential risks that
should be identified. We will learn about risks such as this in the subsequent
sections of this module.
Just as with the risk mitigation that is required to solve the above example, it will
also be useful in addressing conflicts and impediments. As we begin to explore
risk identification and mitigation, keep this in mind:
 The entire team is responsible for conflict resolution, elimination of

impediments and identification of risks. You must act as a facilitator to open
communication, and you must also use your role of servant leader to ensure
the team follows the path of team-based methods toward resolution.
© BetterPM.com 273
2. Risk Identification
Risk is present in any project, including those that are operating within the agile
framework. Because the framework places emphasis on continual communication among
the team members using the least complicated methods, the ability to identify and mitigate
risk is a key benefit of agile. But the risk is still there and must be addressed, and this
section covers the key areas of risk on Agile projects that you are likely to come across.
The 5 Core Risk Areas

Although the Agile framework
does not specifically reference risk
management, the PMI-ACP exam
focuses on five core risk areas that
are common to all projects. These
risk areas are introduced in the
next pages.
© BetterPM.com 274
The 5 Core Risk Areas
Common Across All Software Projects
In their 2003 book Waltzing With Bears: Managing Risk on Software Projects1, Tom
DeMarco and Timothy Lister state that any project worth starting will be vulnerable to risk.
And since greater risk brings greater rewards, companies that completely avoid risk will be
left behind by the competition.
The agile practitioner must be mindful of these
core risk areas on their projects:
 Intrinsic Schedule Flaw

 Specification Breakdown
 Scope Creep
 Personal Loss
 Productivity Variation
On the next pages we’ll review each of these
risk areas. Note that these risks do not apply
solely to software projects.
http://www.amazon.com/Waltzing-Bears-Managing-Software-Projects/dp/0932633609
© BetterPM.com 275
Risk Area 1: Intrinsic Schedule Flaw
Intrinsic schedule flaw is a result of overly optimistic estimates or task durations
that have extended well beyond their baseline. Schedule flaw can result from
wishful thinking or rounds of planning poker that involved group think.
What it means
 Given the intangible nature and uniqueness of software, its development is
inherently difficult to estimate and schedule.
Recommended Solution
 Get the team more involved in planning and estimating. Use collaborative
techniques such as Planning Poker to find a common ground in the estimates.
 Get early feedback from stakeholders and address slippage immediately.
Your Takeaway
 By working in short increments the true velocity of the team quickly emerges
and is visible to all stakeholders who are now more closely involved in the
project.
© BetterPM.com 276
Risk Area 2: Specification Breakdown
Specification breakdown results from the inability of the stakeholders to reach
consensus on what to build. In agile, you should look for warning signs that lead to
deadlock or incomplete specifications that would become a problem during the
build phase.
What it means
 In a software project, it’s when coding and integration begin it becomes apparent that
the specification is incomplete or contains conflicting requirements. In other industries
it’s no different: the builders become unclear what to do based on incomplete or
erroneous specs.
 Use a dedicated Product Manager to make critical trade off decisions.
Your Takeaway
 Agile projects utilize the concept of an ambassador user, subject matter expert (SME),
or customer proxy to play the role of product manager. The idea is that a person or
group needs to be readily available to answer questions and make decisions on the
project.
Reference: http://www.projectsmart.co.uk/top-five-software-project-risks.html
© BetterPM.com 277
Risk Area 3: Scope Creep
Scope creep occurs in agile projects just the same as other frameworks
methodologies such as waterfall. As the project build phase progresses, scope
creep occurs in the form of the requirements inflating over time in a way that
extends the finish date of releasable software.
What it means
 As the project progresses more and more features that were not identified at
the beginning of the project emerge that threaten estimates and timelines.
 Constantly involve your customers and developers. Challenge them on items
that appear to be the most difficult requirements.
Your Takeaway
 Agile projects plan in the regular trade-off discussions about features and
estimates at every iteration boundary. Changes and requirements inflation are
accepted as a fact of software projects and must be aggressively monitored by
the agile practitioner.
© BetterPM.com 278
Risk Area 4: Personnel Loss
Loss of key stakeholders, the Scrum Master, the main executive champion of the
project or even the customer can result in a risk to the project that must be
addressed.
What it means
 Key personnel leave the project taking critical information with them that
significantly delays or derails the project.
 Increased collaboration and information sharing on the team so that no one
person or group keeps all of the knowledge in their heads.
Your Takeaway
 Agile projects practice information sharing techniques and frequent reporting
at daily stand-ups specifically to reduce the risk that only one person has
specific knowledge to a feature.
© BetterPM.com 279
Risk Area 4:
Personnel Loss - Mitigation Techniques
As the old saying goes, think about what would happen if a critical team member
were to “get hit by a bus” or “was to win the lottery.” These information sharing
techniques are a good way to reduce the risk that comes from knowledge sitting
in the head of only one person:
Pair Programming
 Pair programming is an agile technique in which two programmers work
together at the same workstation. One person is the Driver, who writes the
code, and the other is the Observer, or Navigator, who reviews each line of
code as it’s typed. The two people change roles frequently.
Collective Code Ownership
 Collective code ownership states that, “we are a community that owns the
code.” The expectation is one of a single style across the team so that any
team member can modify the code at any time.
 Although this is a proactive way to mitigate personnel loss, it does cause
consternation among team members who maintain a pride in ownership.
© BetterPM.com 280
Risk Area 4:
Personnel Loss - Mitigation Techniques
Collective Code Ownership (cont’d)
 This is an argument not only that a team should pair and explore the project's
code, but also that they should be doing so at all times. The team should
always be able to cover for members who are disrupted by family emergencies
or personal illness.
Your Takeaway
 Agile projects practice information sharing techniques and frequent reporting
at daily stand-ups specifically to reduce the risk that only one person has
specific knowledge to a feature.
© BetterPM.com 281
Risk Area 5: Productivity Variation
Productivity variation results from a difference between the actual performance
of the team and the planned or assumed performance. Productivity variation
manifests itself in the form of timeline extensions, additional iterations and/or the
need to retrain members of the team.
What it means
 Given long project timelines, the sense of urgency to work in earnest is often
absent resulting to time lost in early project stages that can never be regained.
In addition, incorrect estimates can lead to this effect.
 Keep your iterations short, place the right people on the team, and keep the
team involved by playing the role of a servant leader and coach.
Your Takeaway
 By having short iterations, work is time boxed into a manageable iteration
(typically 1-4 weeks) and there is always a sense of urgency.
© BetterPM.com 282
Other Factors that Influence Productivity
Agile methods do not specifically address getting the right people on team,
coaching and team development, but core leadership roles applicable to both
agile and traditional projects. While acting as a coach and servant leader, keep in
mind these potential risks to productivity:
 Parkinson’s Law
• Parkinson’s law is an adage coined in a 1955 essay by Cyril Northcote Parkinson
which states that “Work expands so as to fill the time available for its completion.”
• Another way to consider this concept is: The amount of time which one has to
perform a task is the amount of time it will take to complete the task.
• In other words: In a software project, there’s inherent risk in knowing your deadline
to complete the work before you estimate and perform the work. Knowing the
deadline up front can allow human nature to operate at a natural pace which may
actually finish early.
• The Scrum Master should keep in mind that agile estimation techniques should be
used to help mitigate this risk.
Reference http://en.wikipedia.org/wiki/Parkinson's_law
© BetterPM.com 283
Other Factors that Influence Productivity
 Student Syndrome
• Student Syndrome is a concept established by Eliyahu M. Goldratt in his novel
Critical Chain. It states that “people will start to fully apply themselves to a task just
at the last possible moment before a deadline. This leads to wasting any buffers
built into individual task duration estimates.”
• Student syndrome is similar to procrastination, however it originates from more
altruistic intentions. For instance, a student may ask a professor for an extension on
a project so that it can be delivered with higher quality. But in the final analysis,
procrastination does set in and the new deadline approaches with the student
finding themselves in the same situation that they began.
• In project and task estimating, student syndrome is manifested in a time- or
resource-buffer that is wasted as a late start rather than a reserve for a late finish.
Reference: http://en.wikipedia.org/wiki/Student_syndrome
© BetterPM.com 284
3. Risk Response Strategies
In the preceding pages, we have shown that risk is ever-present, even in agile
projects. We have also suggested that the agile framework is set up to provide
constant opportunity to mitigate the risk. But how, exactly?
In the following pages we

recommend specific PMI
process strategies to
identify and address project
risk.
Following those pages is a

discussion of a number of
risk management tools used
by the agile practitioner.
© BetterPM.com 285
Risk Management Planning
PMI’s Project Management Professional (PMP) knowledge framework defines risk
management planning as
 Increasing the probability and impact of positive events,
and
 Decreasing the probability and impact of adverse events.
Risk management planning processes:

 Planning risk management PMBOK Says….
 Identify risks Because neither the agile
 Perform qualitative risk analysis framework nor PMI directly
address risk management
 Perform quantitative risk analysis techniques, the PMBOK guide is
 Planning risk responses used for reference in the exam.
 Monitoring and controlling risk

Source: A Guide to the Project Management Body of Knowledge (PMBOK® Guide ), 5th Edition (2013 Project Management
Institute, all rights reserved)
© BetterPM.com 286
Risk Response Strategies
So if risk must be taken on to stay competitive, what options are available to the agile
practitioner to identify and mitigate risk on their projects? The image below introduces the
risk response strategies that are used. The following pages review each strategy in greater
detail.
Acceptance Avoidance
The risk is low Make the risk less
enough that we Accept Avoid significant by shutting
will do nothing down the situation or
about the risk scope that generates
unless it occurs. the risk.
Risk
Transference Reduction
Outsourcing or Lessening the severity
handing off the Transfer Reduce of the loss or the
risk to a different likelihood of the loss
group from occurring
© BetterPM.com 287
Risk Response Strategies - Acceptance
Risk acceptance means that you accept or absorb the loss that ensues from a risk when it
occurs. At the same time, any positive benefits are also absorbed, although generally there
is more loss than gain.
Other characteristics of risk acceptance:

 It’s a viable strategy for small risks where the cost of insuring against the risk
would be greater over time than the total losses sustained.
 Self Insurance is an example of acceptance.
 All risks that are not avoided or transferred are retained by default.
• An example is an insurance deductible: Anything not covered due to the deductible
becomes a retained risk, while the insured amount is transferred.
© BetterPM.com 288
Risk Response Strategies - Avoidance
Risk avoidance means that you choose to not perform the activity that carries the risk. You
withdraw from the risk altogether by shutting down the scope involved or eliminate the
department responsible for the risk. It’s a decision to withdraw from or stop involvement
with by closing down that feature.
Avoidance may seem to be a good answer to all risks, but avoiding risks also means losing
out on the potential gain that accepting (retaining) the risk may have allowed. Not entering
a business to avoid the risk of loss also avoids the possibility of earning profits.
Examples of risk avoidance:
 Choosing to not develop a feature that would introduce the risk of rework,
feature creep or litigation with a competitor.
• The agile framework is structured to intrinsically mitigate this risk by promoting
iterative development and retrospectives.
 Electing to not outsource your software development or QA work to eliminate
any risk of communication or language concerns that would extend the
timeline.
© BetterPM.com 289
Risk Response Strategies - Transference
Risk transference can be considered as the corollary to acceptance. In the example of an
insurance deductible that’s the accepted part of the risk, all items covered by the insurance
policy are risks that are transferred to the insurer (the third party.)
Transference is also known as “risk sharing.” In the example of a third-party insurer, the
onus of owning the risk financially is with the insurer, however in most situations the legal
liability is still retained by the buyer of the contract.
Examples of risk transference:

 The outsourcing of some development to a third party under a service level
agreement (SLA) that is beneficial to your timeline or exposure is an example
of the transference of risk.
• Note that outsourcing models can potentially add risk to the project by simply
transferring the original risk to another group that still could impact your
deliverables or timeline if the risk occurs.
© BetterPM.com 290
Risk Response Strategies - Reduction
Also known as “optimization,” risk reduction means reducing the severity of loss or the
likelihood of loss from occurring. Since it’s not practical to completely eliminate or absorb
risks, reduction aims to strike a balance between negative risk and the benefit of the
operation or activity, and the risk reduction and effort applied.
Avoidance may seem to be a good answer to all risks, but avoiding risks also means losing
out on the potential gain that accepting (retaining) the risk may have allowed. Not entering
a business to avoid the risk of loss also avoids the possibility of earning profits.
Software methodologies such as Waterfall suffered from the fact that they only delivered
software in the final phase of development. Any problems encountered in earlier phases
meant costly rework and often jeopardized the entire project.
By developing in iterations, agile projects can limit effort wasted to a single iteration.
© BetterPM.com 291
Risk Management Tools Used in Agile
Some may be concerned that agile or Scrum ignore risk management completely, and in
fact PMI’s PMBOK guide is necessary for referencing risk mitigation techniques. Although
the agile framework does not explicitly reference risk management techniques, it does so
implicitly throughout the framework through its various process and tools. This section
references two such tools that are necessary items in the Scrum Master’s toolkit when risk
management is involved.
 Risk burn-down charts

• A risk burn-down chart is created by plotting the sum of the risk exposure values
from a census of the top risks identified for the project. It is a graphic visualization
that looks similar to the burn-down charts that we have shown in previous
modules.
 Risk-adjusted backlog
• The Risk Adjusted Backlog focuses on where investment needs to be undertaken,
based on risk. A risk assessment database process provides a decreasing list of
priorities from the risk calculation: Potential Consequence x Likelihood.
© BetterPM.com 292
Risk-Adjusted Backlog
In an Agile environment it is the joint responsibility of the whole team to identify risks on
an iterative (sprint) basis. The Risk-adjusted backlog is a tool that involves the collection of
three data points
• Listing of each risk to the project
• Assigning a likelihood score (probability of rich occurrence)
• Assigning a consequence (impact/size of loss in days)
• and then calculate a risk score (called as risk exposure, in days)
The backlog is then revisited during each iteration with the data values updated. The
resulting backlog and burn-down chart are shown on the following pages.
© BetterPM.com 293
Preparing your backlog for a Burn-down
The first step of creating a risk burn-down chart is to prepare the data in the form of a risk
matrix, shown below. This can be done in a simple spreadsheet. Just as with a traditional
burn-down chart, the exposure levels should be gathered on a frequent, consistent basis.
Risk Probability of Size of Loss Risk Exposure
Risk (%) (days) (days)
The features to be developed may require the 20% 10 2
purchase of 3rd party tools to develop.
There will not be enough time for the customer 20% 5 1

to provide adequate feedback on feature A,
which will increase the likelihood it will be
considered an unacceptable deliverable at
release time.
Partner C may require additional testing time 25% 20 5

across all operating systems.
Validation of the features by Partner B will not 40% 5 2

be completed in time.
Exposure: 10
© BetterPM.com 294
The Risk Burn-down Chart
The final step is to create the burn-down chart by plotting the sum of the risk exposure
values from the census as a frequent occurrence.
100
90
Risk Exposure (days)
80
70
60
50 Series1
Ideal risk burn-down
Series2
Actual risk burn-down
40
30
20
10
0
1 2 3 4 5 6 7 8 9 10 11
Iterations
© BetterPM.com 295
4. Risk Communication Techniques
It is the responsibility of the agile practitioner to communicate clearly, openly and at a high
frequency to encourage awareness of the project’s risks by the full team.
Keep these things in mind as you communicate risks to your team
 Your goal should not be to act as the sole person (or bottleneck) who manages
the intake and communication of all risks. Instead, encourage your team to
take collective ownership of the project’s risk mitigation strategies. As with
other techniques in agile, you should ensure that you create a culture of
collaboration and a sense of team.
 Encourage your team to place themselves in the position of the customer.
Risks will emerge most clearly when the team considers all stakeholders and
acts as a collective unit to own the mitigation of risks.
© BetterPM.com 296
Risk Communication Techniques
Use this table to determine when and how each method of risk communication should be
performed.
Activity Suggested Communication When performed
Plan Create a checklist or populate the risk backlog with high-risk Once before the
features. Communicate to the team as an information radiator project starts
Identify Decide whether the feature is high-risk or not by engaging Before implementation
knowledge experts and the broader team. If the feature is a of the feature
high-risk, book risk identification to sprint backlog, otherwise
use light methods like brainstorming or the Delphi technique.
Assess Add the impact and probability of the risk by including it on After identification
the risk backlog. Use concepts similar to planning poker to
ensure that there is a consensus on the impact and probability
rankings
Respond Create responses and make sure they're in proportion to total During feature
risk. implementation
Mitigate Communicate with the appropriate stakeholders any and all Sprint Review
acceptances, transferences, avoidance or reduction.
Monitor Revisit the risk backlog During each
iteration/Sprint
© BetterPM.com 297
 A team of framers on a construction site is unable to determine from the
blueprints what should be done with the format of the north-facing wall. They are
unable to complete this activity because of:
•Specification breakdown
•Inherent schedule risk
•Incorrect documentation
•The lack of a scrum master to provide direction
You need to quantify the risks on an agile project and use it as an information
radiator. You should:
•Create a risk matrix and then plot a risk burndown chart.
•Create a RACI chart and then plot a risk burndown chart
•Paste a detailed risk matrix on the wall for everyone to see.
•Determine the likelihood of risk and then create a burndown chart.
© BetterPM.com
 Which of the following is not a risk response strategy in an agile project?
•Accept
•Avoid
•Transfer
•All are acceptable
The scrum master realizes that there is nobody on the team with the skillset
required to properly build a feature in an upcoming feature. To keep the project
on track, he hires a business partner overseas. This is:
•An unacceptable risk because it transfers the risk to another party
•An unacceptable risk because it avoids the true problem
•An acceptable risk as it transfers the risk to another party
•An acceptable risk because it avoids the problem
© BetterPM.com
Module 8: Continuous Improvement

Module Overview
This final module focuses on the PMI-ACP exam’s Value Continuous Improvement
framework, which addresses Product, Process and People toward an effort of
eliminating waste and achieve quality improvement.
In this module:
• Concepts from Lean
▫ Introduction and history
▫ Learn how to incorporate Lean into your organization
▫ How Lean and Six Sigma can be combined with Agile
• Kaizen
▫ The Kaizen cycle
▫ The five levels of kaizen
• Continuous Improvement Methods in Agile
▫ The Sprint Retrospective
▫ Method Tailoring
▫ Incorporating Feedback
© BetterPM.com 301
Module Objectives
 Tailor the process to the project by adapting practices for the team, organization
culture, and delivery goals in order to ensure that the team is effective within
established organizational norms.
 Incorporate feedback by conducting frequent retrospectives in order to improve
process, individual, and team effectiveness.
 Adjust team composition and work practices to improve efficiency within the existing
process with a goal of keeping a team together long term.
 Remove wasteful process elements by challenging existing process elements in order
become more efficient.
© BetterPM.com 302
Module Objectives (cont’d)
 Create systemic improvements by disseminating knowledge and practices across

project and organizational boundaries in order to avoid re-occurrence of problems
identified, improving the effectiveness of the organization as a whole.
 Improve team member knowledge and skills by pairing team members in order to
improve overall team effectiveness and lowering risk around knowledge silos.
 Evaluate work efficiency in order to identify opportunities to reduce waste.
 Experiment with new techniques and process ideas for short periods in order to
discover more efficient and effective ways of working.
© BetterPM.com 303
Section 1: A History of Lean
Why Lean in an Agile Course?
 Just as we mentioned in earlier modules that the elements of Agile existed in industries
besides software years before the Manifesto was born, so too have other elements of
Agile’s vision: namely, continuous improvement has been a core tenet in many
disciplines. Agile is rooted in many concepts that started as Lean.
A Brief History of Lean

 Starting as early as the Industrial
Revolution in the mid-1700s, a
process to improve quality became a
necessity as a result of the transition
from manual production to mass
production: mass production was
shown to initially produce more
waste before processes were refined
over time. Above: During the Industrial Revolution, Lowell,
Massachusetts was the place to be. Here is the inside
of one of the old textile mills in the Boott Cotton mills
complex.
© BetterPM.com 304
 It wasn’t until the early 1920s in

America that Henry Ford became the
first person to truly integrate an
entire production process. Gone
were the days of manual tinkering
with parts to yield minor variations in
every product delivered.
 Other automakers caught on and
“improved” upon the process to
lower costs, which did occur. But
their process improvements with
heavier machinery increased
throughput times and inventories.
Left: Henry Ford’s Model T became an American
symbol of mass production and its improvements in
costs and quality.
© BetterPM.com 305
 In the 1930s, engineers at Toyota realized that a series of simple innovations

might make it more possible to provide both continuity in process flow and a
wide variety in product offerings. They revisited Ford’s original thinking and
invented the Toyota Production System. Below is a summary of what they did:
 To avoid overproduction, Toyota right-sized machines for the actual volume
needed.
 Self-monitoring machines were introduced to ensure quality
 Machines were lined up in process sequence, pioneering quick setups so
each machine could make small volumes of many part numbers.
 Established a mechanism where each process step would notify the
previous step of its current needs for materials.
As a result, Toyota was able to obtain low cost, high variety, high quality, and
very rapid throughput times to respond to changing customer desires. Also,
information management could be made much simpler and more accurate.
© BetterPM.com 306
Lean Today
As lean thinking spreads today, leaders are also adapting the tools and principles
beyond manufacturing, to logistics and distribution, services, retail, healthcare,
construction, maintenance, and government.
Today’s definition of Lean:

Lean refers to a set of tools designed to improve flow and reduce waste during a
business process or in the manufacturing of a product.
Lean can be practiced on its own or as a part of Six Sigma, which is a set of tools
designed to control business processes by reducing defects and improving quality.
© BetterPM.com 307
Variations of Lean
 Lean manufacturing – more commonly known simply as “Lean” is a goal that considers
the expenditure of resources for any goal other than value to be wasteful, and is
therefore target for elimination.
 Lean’s goal is to create increased value with the lowest number of resources.
 Lean Six Sigma is a managerial concept that results in the elimination of the following
seven kinds of waste (aka “muda”)
 Transportation
 Inventory
 Motion Who is Tim Wood?
 Waiting
 Overproduction Tim Wood is a
 Over-processing mnemonic for learning
 Defects the seven kinds of
waste.
© BetterPM.com 308
Three Key Features of Lean
The Lean discipline focuses on three key concepts:
 Waste – Waste is considered the opposite of value and its elimination is a primary goal
of Lean principles. Anything that the customer does not want or that delivers no value
is waste.
 Complexity – Lean states that simple and straightforward should always be a primary
goal. Four items that add complexity are:
 Quantity of parts (the more parts involved, the higher the complexity)
 Volume, or size of the process
 Density, which is the ratio of the process size to the volume, and
 The Time required to complete a cycle.
 Variation – anything in a production that has variation causes waste. Lean strives to
identify the cause of variation, which come from
 System variations – such as a malfunctioning piece of equipment
 Special cause variations – (an assignable event, such as a weather event closing the factory)
 Structural variations – such as sales cycles: Q4 holiday shopping revenue versus Q1.
© BetterPM.com 309
Lean as Continuous Improvement
 Most concepts of Lean, Six Sigma and the variations of the disciplines all focus on one
key outcome: continuous improvement. Improvements that are not repeatable are not
considered process improvements that are maintainable.
 One tool that promotes
continuous improvement is the
PDCA Cycle, shown at right. This
tool for carrying out change has Plan Do
no beginning or end and should
be repeated for continuous
improvement.
Act Check
© BetterPM.com 310
Plan Do
Act Check
Using Plan-Do-Check-Act
When to use:
 As a model for continuous improvement.
 When starting a new improvement project.
 When developing a new or improved design of a process, product or service.
 When defining a repetitive work process.
 When planning data collection and analysis in order to verify and prioritize
problems or root causes.
 When implementing any change.
The Procedure
 Plan. Recognize an opportunity and plan a change.
 Do. Test the change and carry out a small-scale study.
 Check. Review the test, analyze the results and identify what you’ve learned.
 Act. Take action based on what you learned in the Do step: If the change didn’t
not work, repeat the cycle again with a different plan. If you succeeded, use
what you learned to plan new improvements, beginning the cycle again.
© BetterPM.com 311
Being Lean – Minimal Marketable Feature
 A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it
was any smaller, it would not be marketable. A MMF is marketable, because
when it is released as part of a product, people would use (or buy) the feature.
 Minimal: If a split results in a story too small to be able to market, it shouldn’t

be done. Be sure to agree with your customer on the definition of “done.”
 Marketable: Ask yourself if the feature is marketable.
 Feature: A feature is known as demonstrable behavior of the product.
Something that is perceived by the customer as having value.
 What’s the difference between a user story and an MMF?

• An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to
launch on its own.
• A MMF can be represented as a User Story — a short, one-sentence description.
• But in contrast to how a User Story is typically used, the team would not break
down the User Story into smaller User Stories when using MMFs
© BetterPM.com 312
Being Lean – Enterprise Risk Management
 Thinking in terms of your organization’s total cost of risk leads to discussion
such as regulatory compliance, business continuity and emergency response
scenarios.
 Strong requirements up front serve as effective inputs to the agile team’s
processes, and lead to strong incremental delivery as outputs. Exposing risks
early pays off later.
© BetterPM.com 313
Section II: Kaizen
Similar to Lean its goals of continuous improvement is the concept of Kaizen, which is a
Japanese philosophy which means “good change,” or “change for the better.” The term was
coined by Masaaki Imai in his book Kaizen: The Key to Japan's Competitive Success
Kaizen was first implemented in Japan during the restoration period following World War II.
The methodology includes making changes and monitoring results, then adjusting. Large-
scale pre-planning and extensive project scheduling are replaced by smaller experiments,
which can be rapidly adapted as new improvements are suggested.
The Toyota Production System mentioned in the start of this module is known for kaizen,
where all production line employees are expected to stop the line if an abnormality if
found, and then they must suggest an improvement to resolve the abnormality.
On the following page is the cycle of kaizen activity, which operates very much like the
PDCA model.
© BetterPM.com 314
The Kaizen Cycle
The cycle of activity in kaizen can be defined as:
 Standardize an operation and activities.
 Measure the operation (find cycle time and amount of in-process inventory)
 Gauge measurements against requirements
 Innovate to meet requirements and increase productivity
 Standardize the new, improved operations
 Continue cycle ad infinitum
Other Names of the Kaizen Cycle
• Shewhart Cycle
• Deming Cycle
• PDCA
© BetterPM.com 315
Kaizen Events
An application of the kaizen concept to effect continuous improvement is the use
of Kaizen Events. They are an extremely efficient way to quickly improve a process
and are also useful for convincing organizations new to Six Sigma.
Kaizen Events are commonly referred to as events that:

1) Gather operators, managers, and owners of a process in one place
2) Map the existing process (using a deployment flowchart, in most cases)
3) Improves on the existing process
4) Solicits buy-in from all parties related to the process
The end goal of the kaizen event is to tear down and rebuild a process so that
functions more efficiently and with less waste.
© BetterPM.com 316
The Five Levels of Kaizen Events
Kaizen Events can occur at five different levels:
Individual
Mini Point Kaizen
Kaizen Blitz
Flow Kaizen
Supply Chain Kaizen
© BetterPM.com 317
Kaizen Level 1: Individual
Definition: An individual should constantly strive to reduce waste and improve efficiencies
from their vantage in the overall process. As kaizen is meant to be a constant process, it
requires a personal, long-term commitment to change.
How to Use it:

• Challenge yourself to learn new skills
• Keep a log file, a digital note pad, or use an online blog to record ideas that may help
the team later.
• Get out of your comfort zone (yet still adhere to the rules of the project)
© BetterPM.com 318
Kaizen Level 2: Mini Point Kaizen
Definition: At the next level, the individual works with their team to improve a part of the
process. This team typically should be the immediate team that he she is involved with, and
it works best in groups of six.
How to Use it:

• The team works to consider changes to a particular process or workflow that has
immediate impact to their daily work experience.
• The level is often done as an ad hoc event or potentially as a small workshop on the
spur of the moment. The idea is to come together quickly and brainstorm ideas that
could have application to the larger group or process.
© BetterPM.com 319
Kaizen Level 3: Kaizen Blitz
Definition: Also known as the Point Kaizen, the blitz is a larger version of the mini point.
The group can be larger, the duration of the meeting can be longer, and larger issues (such
as cross functional processes) are discussed.
How to Use it:

 Schedule it is a focused, multi-day event to deliver specific performance
improvements (but it could be shorter than five days). Participants include all
the right people to analyze the problem, develop improvement solutions and
begin to implement them.
 Management must commit to the time and resources required, and to
empower the Blitz team to “do what is needed” to achieve improvements.
© BetterPM.com 320
Kaizen Level 4: Flow Kaizen
Definition: Continuing in a natural progression of an increasing audience and larger issues,
the flow kaizen addresses departmental or divisional concerns and involves process
changes that are cross functional.
How to Use it:
 Executive sponsorship generally initiates the flow kaizen, as it is a significant
transformative event that pulls together thought leadership from all disciplines
to address full process cycles.
 Flow kaizens are not performed on the spur of the moment, nor are they
performed as a part of an Agile project, but individual teams may be called
upon to contribute information toward these sessions.
© BetterPM.com 321
Kaizen Level 5: Supply Chain Kaizen
Definition: The supply chain kaizen increases the scope and audience yet again, this time
involving other groups and organizations in the overall supply chain.
How to Use it:
 Executive sponsorship from each company or group is mandatory for a supply
chain kaizen. It is likely that you will be made aware of them as part of overall
transformational strategies or multi-year visions.
 A product manager, consultant and documentation of all existing processes
and the other kaizen levels are almost always present.
© BetterPM.com 322
Section 3: Continuous Improvement in Agile
Never underestimate the value of continuous improvement. Agile teams naturally get
better over time, and there may be a tendency to skip certain steps or meetings. Yet
continuous improvement requires you to constantly strive to do better, which means that
even (for instance) a sprint retrospective should still be held even on a highly successful
sprint.
A good Scrum Master will always find ways for even the most refined process to be
improved. And a truly successful agile team is one who constantly evolves by never
entering the comfort zone that’s brought on by sticking to “tried-and-tested” methods.
Techniques to use to continuously improve:

 Ensure that you are capturing value from the viewpoint of the customer.
 Eliminate any steps that detract from the creation of value.
 Fine-tune each value step that is involved in the creation process. The goal is to deliver
a steady stream of incremental value to the customer.
 Ensure that your customers are able to see value as a result of each release.
 Create a system and a culture of continuous improvement.
© BetterPM.com 323
Continuous Improvement with the
Retrospective
The Sprint Retrospective is one of the most significant tools in the Scrum Master’s arsenal
for ensuring continuous improvement. As a member of the team, it’s important to make
sure you contribute to the process and expect the same from your team. If you skip or fail
to generate value from the retrospective, you’re likely to fail to improve.
Recall the Agile Manifesto

• In the first sentence we see, “uncovering better ways.”
– Uncovering better ways likely requires trying new things and seeing how they work. This
is where the retrospective is necessary.
• In the 12th principle, we see, “At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior accordingly.”
– It is often called “inspect and adapt,” which start by doing things, learning, and improving
along the way.
– Example: Just like you don’t know all requirements up front when you start developing a
product, you start working with what is clear and needed and then change based upon
the feedback. Retrospectives are a way to “embrace change” in the way you work as a
team.
© BetterPM.com 324
Method Tailoring
One distinguishing characteristic that sets agile apart from other disciplines is its
embracing of the concept of method tailoring, which allow project teams to adapt
working practices according to the needs of individual projects.
Method tailoring defined:

A process or capability in which human agents determine a system development
approach for a specific project situation through responsive changes in, and
dynamic interplays between contexts, intentions, and method fragments*
This situation-appropriateness is used explicitly in eXtreme Programming (XP,)

which posits that no one process fits every project, but rather that practices
should be tailored to the needs of individual projects.
* Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information
Systems Development Method in use
© BetterPM.com 325
Method Tailoring in Agile
• Potentially all agile methods are suitable candidates for method tailoring.
• Keep in mind that many organizations practice a blend of disciplines, with Agile
being among many, and with team members potentially being shared among
projects. Variations in an organization’s use of the Agile framework to fit the
situation is a good example of real-world method tailoring.
▫ A rigid, one-size-fits-all expectation for every agile project in your company will
likely lead to failures and adoption issues.
▫ Some organizations will adopt agile completely and across the board, whereas
others will have only some product lines perform agile. It is not uncommon to see a
mixture of Agile and SDLC practiced in the same company, or for Lean Six Sigma
black belts and PMP-certified project managers to be assigned to an Agile team.
© BetterPM.com 326
Incorporating Feedback
Agile methodologies seek customer feedback throughout the life of a project.
Projects that run via an agile discipline know that for a project to be successful,
the customer will need to be happy. And one way for the customer to be happy is
to deliver incremental features to them and get their feedback.
According to Jeff Sutherland, one of the principal authors of the Agile Manifesto,
“Even when traditional projects finish on time, on budget, with all features in the
plan, customers are often unhappy because what they find is not exactly what they
wanted.” If you wait until the end of the project to give a preview to the customer,
it will be too late and they will be unhappy, which ultimately leads to rework.
All types of the agile discipline have built-in processes to ensure that the plans can
be changed according to feedback from the customer. The results of the iteration
demo should be taken seriously, as this is a key opportunity to hear from the
customer.
Reference: http://msdn.microsoft.com/en-us/library/dd997578.aspx
© BetterPM.com 327
 True or False: a flow kaizen is designed to be introduced quickly to a company
once it realizes it is needed.
•True
•False
•Velocity
•Sprint Estimation
If you are reviewing a test, analyzing the results and identifying what you’ve
learned, you are performing:
•The Check portion of the Plan-Do-Check-Act process
•The Act portion of the Plan-Do-Check-Act process
•Test Driven Development
•Risk mitigation
© BetterPM.com
 A set of tools designed to improve flow and reduce waste during a business
process or in the manufacturing of a product is known as:
•Kaizen
•Kanban
•Agile
•Lean
The belief that that no one process fits every project, but rather that practices
should be tailored to the needs of individual projects is a component of:
•Extreme Programming
•Lean
•Method Tailoring
•Both A and C
What is another name for the Kaizen Cycle?
•HaShiRa
•Shewhart Cycle
•Kanban
© BetterPM.com

PMI ACP Exam Prep

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PMI ACP Exam Prep

Загружено:

Авторское право:

Доступные форматы

PMI-ACP Exam Preparation Course

Aaron MacDaniel, PMP, CSM, MBA

are directly related to the

 Upon completion of this course, you are entitled to earn 21 PDUs.

 Module 3: Stakeholder Engagement

 Module 5: Adaptive Planning

 Module 7: Continuous Improvement (Product, Process, People)

Aaron MacDaniel, PMP, CSM, MBA

This module is intended to summarize the

Examination • Tests knowledge of all agile fundamentals

The exam consists of 120

Twenty of the questions are

The exam is split evenly

The three knowledge and skill levels are

• Level one contains 33% of the

Aaron MacDaniel, PMP, CSM, MBA

Throughout this course, in conversations among project managers & software

In the past 15 years, the agile

Feasibility Why the name waterfall?

Because other than some

Waterfall doesn’t prohibit going back “upstream” to fix

 Individuals and interactions over processes and tools

1. Our highest priority is to satisfy the customer through early and

5. Build projects around motivated individuals. Give them the

9. Continuous attention to technical excellence and good design

Infrequent team communication Continuous team communication

Must nail down requirements up front Expects, accommodates, changes to

Agile Practices Agile Management

 An alternative to the concept of cost accounting in business today (which focuses on

 A product owner creates a prioritized wish list called a product backlog.

 The sprint ends with a sprint review and retrospective.

Sprint Backlog Backlog tasks 2-4 weeks

These items are not necessarily the same relative size

Story To Do In Dev Test Complete

As a User, I… Code the Test the

 Each participant in the Daily Scrum is known as either a chicken or a pig,

And here is how the mythical conversation would go:

 Chicken: “Let's start a restaurant!”

 Pig: “What would we call it?”

 Chicken: “Ham n' Eggs!”

 Pig: “No thanks. I'd be committed, but you'd only be involved!”

Today’s Message: The concept of chickens and pigs may occasionally

 The Official Scrum Rulebook1 (October 2011) by Ken

 The following slide visualizes the various roles of the team

Scrum Roles Product

Ahead in the next module:

 In particular, we’ll cover Agile Modeling, Empirical Process Control, and

 One such variation of Agile that is gaining acceptance in large organizations is

Aaron MacDaniel, PMP, CSM, MBA

 Assess Ways to Maximize Value and Minimize Waste

The primary role responsible to the

Scrum Roles Product

According to Schwaber and Sutherland

 The user story is used to capture the customer’s (or

 One tool used is a simple document template called

User stories in future major releases

Example: Consider five stories, each of varying size.

 Individual stories are presented for

Release every sprint Daily Scrum every 24 hours

On the following slide is an example of a sprint backlog as an output of the

A reminder that other

To prevent a loss of momentum, the following situations should be

 In the following pages we showcase a number of options that are available to

Terms used in Velocity Tracking