Make New

Programs
Succeed.
PMI-ACP EXAM CHEAT SHEET (AGILE PMP) Catego
12/20/2019 2 Comments
ries
All

Arti8cial Intelligence

Business Development

Customer Intelligence

Data Privacy

Data Protection

Demand Generation

Growth Hacking

Industry Analysis

Leadership

Market Opportunities

Product Management

Product Market Fit

Program Delivery

Studying for the PMI-ACP agile PMP exam? For this test you not only Project Management

have to understand and have lived agile processes, you have to SaaS

remember a lot of terms: names of techniques, collaboration games, lists Strategy

of principles, etc. Here is a cheat sheet to review before the exam, to

help answer all the trick questions.

I've also included a comprehensive inventory of free PMI-ACP online

tests, over 1,400 questions in total. With a cost of ~$400 for this test, it is

deRnitely worth going through all the free mock exam material to make

sure you are thoroughly ready. Good luck!

Online PMI-ACP Practice Exams:

Simplilearn 120 Questions

PMIACP4U 120 Questions

PM-Training 120 Questions

PM Aspire 60 Questions

Agile Mercurial 50 Questions

Exam Topics 700 Questions

Agile PrepCast 84 Questions

360PMO 25 randomly selected from 120 Questions

Master of Project Academy 20 Questions

AGILE VALUES

Individuals and interactions over processes and tools

Working software over comprehensive documentation

(documentation should be barely sufRcient)

Customer collaboration over contract negotiation

Responding to change over following a plan.

12 AGILE PRINCIPLES

W. Customer Satisfaction - our highest priority

X. Welcome Changes

Y. Frequent Delivery

[. Collocated Team

]. Motivated Individuals

^. Face-to-face Conversation

_. Working Software

`. Constant Pace

a. Continuous Attention

Wb. Simplicity

WW. Self-Organization

WX. Regular Refection

SCRUM

Values: Commitment, Courage, Focus, Openness, Respect

3 Pillars

W. Transparency

X. Inspection

Y. Adaptation

Product Owner (PO) is responsible for maximizing the value of

the product and the work of the team

1 PO per team, but only 1 backlog for the whole product

Responsible/accountable for backlog management

The product owner represents the customer, users, and

stakeholders. Take risk into account when prioritizing

backlog

Development Team

self-organizing, has all the skills needed, no titles, no sub-

teams

"share 2 pizzas" = team size between 3 and 9 (not counting

PO and Scrum Master). Other sources say the optimal team

size is 8, others say 12.

Scrum Master ensures the team understands and enacts Scrum

humility, servant leader

coaches the dev team and removes impediments

Team practices Sashimi to ensure every slice of functionality

delivered is complete

Read more: PMP Exam: Trick Questions Cheat

Sheet.

EXTREME PROGRAMMING (XP)

Values: Simplicity, Communication, Feedback, Courage, Respect

12 Practices

W. Pair Programming - one person codes—the driver. The

other person is the navigator, whose job is to think

X. Planning Game

Y. Test Driven Development (TDD)

[. Whole Team - everyone sits together, generalized

specialists

]. Continuous Integration

^. Refactoring

_. Small Releases

`. Sustainable Pace

a. Collective Code Ownership - multiple people work on all

the code, any pair of developers can improve or amend any

code.

Wb. Coding Standard

WW. Simple Design

WX. System Metaphor

Roles: Coach (= Scrum Master), Customer (= Product Owner),

Developers, Testers

Pair programming is the most helpful technique in

implementing collective code ownership in a team

Code goes through 4 levels of completion: Broken, Build, Ready

for demo, Ready to release

LEAN

Lean focuses on the Value Stream

The 7 Lean principles:

W. Eliminate waste

X. Amplify learning (=early feedback loop)

Y. Decide Late (=defer as long as responsibly possible)

[. Deliver Fast (=get value to the customer quickly)

]. Empower the team

^. Build integrity in (= test throughout, not just at the end)

_. See the whole (=see the system not just the parts)

Nonvalue-added time in Lean is the time in the cycle where we

Rnd delays, waste and constraints.

Examples of Waste

Partially done work (e.g. untested code)

Extra processes (e.g. approval from manager who is not a

true stakeholder)

Extra features (gold plating)

Task switching (e.g. if you're assigned to multiple projects)

Waiting (e.g. waiting on sign-offs)

Motion (e.g. poor communication between teams)

Defects

KANBAN

A key tool in lean manufacturing

Focused sustainable pace and regular JIT delivery of individual

items. Optimize the fow.

Core Practices

DeRne and visualize the workfow

Limit Work-In-Progress (WIP)

Measure and Manage Flow

Make Process Policies Explicit

Use Models to Suggest Improvement

In practice, start by 1) visualizing the fow of work to identify

bottlenecks, 2) speed up or remove the bottlenecks that affect

overall throughput 3) establish WIP limits, and then 4) look for

continuous improvement.

Compared to Agile, Kanban focuses on continuous aow (vs. Rxed

iterations) and cycle time (vs. velocity)

Cycle time = # completed items/# days, the average time

between the delivery of completed work items. For example 10

completed items in 5 days means a cycle time of 0.5 days/item.

Task Board serves the dual purpose of giving the team a

convenient mechanism for organizing their work and a way of

seeing at a glance how much work is left. Can be a whiteboard,

cork board, cardboard, etc.

Lets you visualize the workfow and identify constraints.

On a task board you have 3 basic columns: to-do, in-

progress, done.

The WIP number on the board is the max number of work

items in a swim lane.

Kanban board uses a pull system

Little's Law: # of items in the system = Rate items enter the

system x Average time items spend in the system.

Demonstrates that the duration of work queue is dependent on

its size. Following Little's Law, to improve cycle

time, reduce WIP (work in progress) and increase ACR (average

completion rate).

Throughput is the number of features the team can develop in a

particular amount of time.

A testing team Rnds that it is often in the Rring line as they often

have more work than they can handle. In the Kanban system the

best way to handle this is to limit the WIP. This will address the

feeling of being overwhelmed with work and pave the way for

more creative solutions to the problem.

David Anderson 5'S for Kanban agile development: Set in order,

Sort, Shine, Standardize, Sustain

Scrumban is a hybrid of Scrum and Kanban

AGILE CHARTER AND PROGRAM

Agile charters answer the W5H questions (who? what? where?

when? how?)

Charter doesn't specify costs or speciRc team members

If the charter doesn't exist, create one with the sponsor

5 Phases of Agile Project Management: Envision, Speculate

(including release plan and stories), Explore, Adapt, Close

Planning Onion: Strategy, Portfolio, Product, Release, Iteration,

Day. Team is mainly involved starting at Release.

4 types of revenue

New revenue (from new markets, customers, features)

Incremental revenue (existing features are enhanced, add-

on's, encourage customer to buy more)

Retained revenue (what you will lose if you don't develop

key features, could relate to regulatory)

Operational EfRciences (internal improvement)

Read more: 12 Shocking Facts about Scrum

Methodology.

PLANNING TECHNIQUES

In agile you will spend more time planning overall than in

waterfall! However the planning is spread out over the course of

the project.

Vision and requirements gathering:

Design the Box - break into small groups and design the

product name, graphic, elevator pitch on the front, detailed

features on the back, and operating instructions

Prune the Tree - a requirements gathering technique

Remember the Future

Prioritization:

MoSCoW

Must Have – Critical to the current delivery timebox

in order for it to be a success

Should Have – important but not necessary for

delivery

Could Have – Desirable, but not necessary; Could

improve user experience or customer satisfaction for

very little cost

Won’t Have – Have been agreed by stakeholders as

the least-critical and not to be delivered in the

current timebox

MustHave+ShouldHave = business

case. Must+Should+Could = business case +

contingency, 100% of total.

Kano Analysis:

Exciters/Delighters – features deliver unexpected

beneRts to the customer

Performance/Satis8ers/Threshold/Must-Have –

features deliver expected beneRts to the customer

Basic/Dissatis8ers – If these features are missing,

customers will be unhappy

Indifferent – Customers do not care if these features

are in the product or not

Performance – Linear relationship between

functionality/quality and customer

satisfaction

Excitement – Customers will be willing to pay

premium for these features, lack of features

will not decrease satisfaction

Basic – Making these better, will not improve

customer satisfaction, best is neutral •

Indifferent – Minimize these features

inclusion

Basic/DissatisRers are most important

compared to Delighters or SatisRers. This will

cause the customer to dislike a product if

they are not present. Indifferent features

should be minimized or eliminated.

Relative Weighting - priority of a feature is determined by

dividing the priority % by the cost %

Bang for the Buck, Buy a Feature, 100 Point Method

Estimation

Af8nity estimating (e.g. T-Shirt sizing) is the practice of

using common sizes to rapidly place user stories into

similarly sized groups - good for when you have at least 20

stories, ideally 40 stories or even 100s of stories. Each story

is placed on a table and one by one a team member is

given an opportunity to place a card in line or adjusting a

card in the line already.

Wideband Delphi (e.g. Planning Poker) estimation

includes plotting estimates on a chart with no names, and

then the range of points is discussed, and the team

attempts to reach a general consensus. Wideband Delphi is

anonymous estimates which minimizes the Bandwagon

effect, HIPPO decision making and Groupthink

Decision making: Fist to 8ve, thumbs up, thumbs down or

thumbs sideways, and decision spectrum, Dot Voting

(stickies), Forced Ranking (score criteria, then rank in order based

on score)

Buy a story is a collaboration game to help stakeholders

understand a complex issue

Brainstorming: Round robin, Quiet Writing, Free for all.

Collaboration: Listening Game, Collaborative Origami, 123 Go

BACKLOG, EPICS, USER STORIES

User stories are not the same as "use cases" or "design scenarios".

They are support tools for analysis.

User stories should be written following INVEST principles:

I: Independent

N: Negotiable

V: Valuable

E: Estimable

S: SpeciRc (or Small)

T: Timely (or Testable)

Each story has 3 elements, the 3 C's

the Card (the story should Rt on a 3" x 5" card)

the Conversation (user stories are communicated by end-

users to developers)

the ConRrmation (the acceptance criteria)

A story map is like a product roadmap, using future stories to be

implemented. Story mapping is used to identify missing stories,

categorize stories into functionality and prioritize stories.

Epic stories are large stories that have not been broken down,

and these are typically found at or near the bottom of the product

backlog.

Disaggregation refers to splitting a story or feature into smaller,

easier-to-estimate pieces (NOT decomposition)

Small stories such as cosmetic UI changes and reading/writing

bug reports can be combined into larger stories

Spikes: architectural spike (e.g. proof of concept), risk-based spike

Research stories should last 1 day

Acceptance criteria come from the customer, even if ultimately a

team member might be the one to write them down

Theme is a set of related user stories that may be combined

together and treated as a single entity for either estimating or

release planning.

Quantity of function is scope measured in terms of user stories,

use cases, requirements, or features

The risk-adjusted backlog is a primary way in which risk is

managed. Stories in a risk-adjusted backlog are prioritized

based on EMV (expected monetary value).

Grooming the backlog = re8nement = adding detail,

add/remove stories, prioritize

RELEASE PLANNING, ITERATION PLANNING and STAND-UPS

When release planning:

slice stores

estimate velocity

select stories

Waves/milestones are intermediate 1-3 month timeframes with

story-level capability and commitment. When a milestone is

achieved, someone can verbally announce it ("declaration

milestone")

De8nition of ready determines when an item is ready for

development (ie. when it can go into an iteration)

Staging is the process of deRning and prioritizing the

nonfunctional requirements. Occurs prior to the start of the Rrst

Sprint and takes just one day.

Iteration planning includes the deRning of tasks on an agile

project. Break stories into tasks during iteration planning

Tasks are self-assigned by the team. If no one wants a task, the

team collectively decides. Task assignments are done by the team

in a self-organized agile team

Tasks are estimated at the time of Iteration Planning as well as

during the iteration

The PO shouldn't attend the standup which is a meeting of, for,

and by the team

End of iteration demo is called a product review meeting

AGILE PROJECT SCHEDULE

The agile project schedule is created by estimating story points

and applying velocity.

Sprint 0 (or 'Iteration 0') does not deliver customer value. It can

include initial training.

Actual time is the amount of time an assignment would take to

complete. Ideal time is the amount of time an assignment would

take if there were no interruptions or distractions. The conversion

to elapsed time depends upon individuals involved but can

usually be reasonably estimated at an aggregate or team level.

If project is release-timeboxed, a team can maintain a feature

buffer and follow a MoSCoW scheme to logically sequence the

work.

To avoid bottlenecks, it is recommended to get the team to be

generalists so anyone can pick up any task.

Biggest advantage to delivering incrementally is that it reduces

the amount of rework by Rnding issues earlier.

Velocity = number of story points a team can complete in a single

iteration

A team's velocity is not likely to be comparable to another one, so

using industry standards or using velocity to compare to teams is

meaningless. Calculate velocity in the early sprints by team

consensus or using team capacity. Compare teams by ROI, not by

velocity.

The team should get to predictable velocity

Lead time is the amount of time needed to get a feature from

inception to live deployment (not velocity)

Feeding buffer is applied to stories that depend on other stories,

in case the dependencies are late

RETROSPECTIVES

Format of meeting (15-60min):

W. Set the stage

X. Problem solving: gather data, generate insights, decide

what to do

Y. Closing

Set the stage

Everyone sits in circle or semi-circle

Techniques: Check In, Focus On/Off, ESVP and Working

Agreements.

ESVP is a technique used to anonymously identify

team members' attitudes towards retrospectives as:

Explorers, Shoppers, Vacationers, Prisoners.

Generate insight techniques: Brainstorming, Pair Interviews

Force 8eld analysis = analyzing factors that drive change and

restrict change

Decide what to do techniques: Short Subjects, Triple Nickels,

Voting with Dots

Closing techniques: Plus/Delta or Speedboat to ask what team

want more/less in next iteration regarding process.

ARCS, criteria for evaluating Instructional designs:

Choose activities that help people stay engaged so they

don’t drift off (Attention)

That are relevant to the goal (Relevance).

You want activities that people can accomplish

successfully (ConRdent/Competence).

Finally, make sure activities Rt into the overall design so

people think the retrospective is a good use of their time

(Satisfaction).

Return on Invested Time (ROTI) is used to determine the quality

of the retrospective.

You have Release Retrospectives, Project Retrospectives, Iteration

Retrospectives and Surprise Retrospectives.

Surprise Retrospective is conducted when an unexpected event

changes your situation.

AGILE MODELING

Agile modelling techniques are:

use cases

data diagram

screen designs

DEVOPS

DevOps helps speed up the deployment of products from

development to operations

Continuous integration (CI) is executed when code changes are

checked in and tested daily. CI components include source code

control system, build tools, test tools, scheduler/trigger,

notiRcations BUT NOT UNIT TESTS

AGILE CONTRACTS

If schedule variance is expected, use graduated Rxed price

contracts (when both parties share some of the risk and reward

associated with schedule variance)

A DSDM Contract focuses on work being "Rt for business purpose"

"Money for nothing" in Agile contracting created by Jeff

Sutherland means customer can terminate early

INFORMATION RADIATORS, KPIs

Information radiators include: burn charts, retrospective learnings,

story maps (but not the deRnition of done)

Some stakeholders may want a vision statement. Next most

detailed is the roadmap. Then the detailed release plans and