PMI-ACP® Exam Study Sheet

After several rounds of teaching the PMI-ACP® Prep course, I've compiled this list (see attached pdf) of ideas and acronyms that students need to memorize for the exam. I'd love to organize it a bit better--but for now this is what I've got. Students report it's been very helpful in studying.
Let me know if you've got ideas on how to organize it better!

PMI-ACP® PREP NOTES: Coaching Agile Teams

PMI-ACP® STUDY NOTE SERIES: Coaching Agile Teams by Lyssa Adkins

What's On the Exam

     Five Levels of Conflict
This is easy to make into one or more test questions--memorize what each level corresponds to, by number. Typical questions will present a team scenario, followed by the question--what level of conflict is present? Or you may be asked about appropriate interventions, also listed below. For more info, refer to the book pages 204-214. 

• 5. world war: destroy the other / little or no language; intervention: break up the contenders
• 4. crusade: protecting one's own group / ideological language; intervention: use intermediary diplomats to transfer ideas from a neutral perspective
• 3. contest: winning trumps resolving / personal attacks; intervention: accommodate, negotiate, or do some fact-finding and sharing
• 2. disagreement: personal protection trumps collaboration / guarded & ambiguous language; intervention: support individual perspectives & provide an environment of safety
• 1. problem to solve: information sharing & collaboration / open & fact-based language; intervention: advocate for collaboration or consensus

May be on the Exam, in a General Sense

     A coach's job is to transfer skills to the team. A coach succeeds when the team no longer needs help on a daily, or even weekly, basis.
     Learn about the individuals, in order to build a team (e.g., Journey Lines, Market of Skills, Constellation, Values; see Games listed in Agile Retrospectives prep notes)
     Create Team Norms:
          Being Bold isn't Bad
          Share the work = share the credit
          Notice when someone needs help and offer it
          Preserve open communication, even when it's not comfortable
          Keep it Simple
          Don't struggle more than 30 minutes without asking for help
          No stinky food!
          Consensus Check (fist of five)--quick way to decide
    Expect High Performance
    Master Yourself: learn to recognize the fears within so they don't cloud your vision.
    Let Your Style Change (adaptive coaching). Just like we wouldn't ask someone's to take their first bike ride to be on a steep mountain trail, we don't want to give new agile teams advanced challenges. Find out what they're good at, and challenge them with the next level.
   A coach plays many roles: Coach/Mentor, Facilitator, Teacher, Problem Solver, Conflict Navigator, Collaboration Conductor

Not on the Exam
These are lines that give you a sense of how a great coach can set the stage for open discussion and safe learning:
     p. 94 "I want to let you know that, in this moment, I see courage in you that is palpable."
     p. 126, sprint planning facilitation: "'Which of these agenda questions do you know the answers to right now?' Asking this question helps them keep track of their progress while clearly reinforcing that the responsibility for sprint planning resides with them"
     p. 245 "I'm observing something about this conversation… let's do a fist of five on this statement: 'I'm excited about this conversation, and I am freely contributing my ideas with ease'".
     p. 249 bring them back together: circle counting or silent mind mapping. see Games
     Refer to the book for Agile Coach Failure/Recovery & Success Modes
         

PMI-ACP® PREP: Agile Retrospectives

PMI-ACP® STUDY NOTE SERIES: 

Agile Retrospectives: Making Good Teams Great by Esther Derby & Diana Larsen

What's On the Exam

First, review my favorite ideas from the book, published previously. The following is what's important for the exam.

Know the phases of a retrospective, and what a retrospective facilitator does in each phase

• Set the Stage (sets scope & timebox of meeting; helps people warm up to the space & get present)
• Gather Data (collects multiple perspectives in a way that no one dominates)
• Generate Insights (asks the team to interpret what they see)
• Decide What to Do (asks the team if they'd like to propose any changes based on what they've just discussed; limit this to 3 changes or less until the next retro!)

Know this acronym and when it's used (SMART goals are proposed changes during Decide What to Do; the criteria for evaluating whether it's an attainable goal are below):
     SMART: specific, measurable, attainable, relevant, timely

May be on the Exam, in a General Sense

Facilitation Tips
     begin by asking everyone to speak
     notice who didn't chime in, and ask for their opinion
     "if we had that, what would we gain?"
     observe: "I'm hearing labels and 'you' language"
     observe: "I'm hearing side conversations"
     steer: "can you say that using 'I' language?"
     "What just happened?"
     at the board: write down the exact words of the speaker
     once it's written down, some people drop an issue; remind them to own it
     if the leader speaks, it "quashes group discussion"
     set up deliberately, simple instructions, ask for questions
     debrief every activity
     ask the team to monitor their own working agreements
     point to a working agreement posted on the wall rather than interrupt verbally
     your primary responsibility is to the needs of the team, not to individuals
     examine both facts and feelings

Retrospective Tips
     avoid the F word ("feelings")-- ask about high points & low points, excitement & dread
     do your homework before a retro -- check your assumptions, find out what to focus on
     plan for shuffle time (unusable time between activities as people move to another seat or stand up)
     change rooms for a fresh perspective
     change seating arrangements -- semicircle to open, small circles for working groups
     do pair interviews
     we want to break habitual thinking, so change the format
     take time to develop concrete plans for achieving any retrospective actions--plan together!
     pick only 1 or 2 experiments for the next iteration
     Change pattern: loss, chaos & disorientation, idea clicks, practice & integration

Not on the Exam

The following isn't likely to show up on the exam, but I've included it as a guide to remember what's in the book. Brief game descriptions follow this next block quote; refer to the book for more detail.

Set the Stage: (check in; focus-on, focus-off; ESVP [explorers, shoppers, vacationers, prisoners]; working agreements)
Gather Data (timeline; triple nickels; color code dots; mad sad glad; locate strengths; satisfaction histogram; team radar; like to like)
Generate Insights: (brainstorming-filtering; force field analysis; five whys; fish bone; patterns & shifts; prioritize with dots; report out with synthesis; identify themes; learning matrix)
Decide What to Do: (retrospective planning game; SMART goals; circle of questions; short subjects)
Close the Retrospective: (+/delta; appreciations; temperature reading; helped, hindered, hypothesis; return on time invested)

Focus On / Focus Off
     Inquiry… rather than Advocacy
     Dialogue… rather than Debate
     Conversation…. rather than Argument
     Understanding… rather than Defending

Triple Nickels
     (break out into groups of 3-5 people)
     5-min: Silently, on a sheet of paper, brainstorm on what to do.
     5-min: pass it on, build upon the ideas on your neighbor's sheet
     5-min: repeat up to 5 times

Color Code Dots
     do a Timeline, then use color to indicate how you felt about those events

Mad Sad Glad
     write on color coded index cards, add to wall

Identify Strengths
     pair up; interview the other party
     ask about the high point(s) of something big--the release, a person's career

Satisfaction Histogram
     on a scale of 1-5, dot how you feel our team is doing

Team Radar
     similar to a Blond ROTI
     scale of 0-10, name several axes
     dot-vote

Like to Like
     everyone writes 3 cards each (9 total): keep doing; stop doing; start doing
     take turns; do apples to apples judging; give winner the cards

Force Field Analysis
     list enablers and detractors to this change
     draw arrows towards the center line, thickness indicates strength

Fishbone
     Problem, who, what, when, where, why

Patterns and Shifts
     (after a timeline or mad sad glad)
     ask: where do you see patterns?
     where did things shift?
     do you see connections between events?
     how do these patterns or shifts connect to our current problems?

Dot Voting
     quantity of dots should be about 1/3 or 1/2 total choices available
     (greatly influenced by the question):
     What is most important?
     What will have the greatest impact?
     What do you want to work on most?

Circle of Questions
     use it to decide what to do.
     clockwise talking stick; first person asks 1 question, next person answers
     after answering, become the questioner, on a follow-up question or new topic

Plus/Delta Variants
     keep/drop/add
     mad/sad/glad
     proud/sorry
     plus/minus

Temperature Reading
     Explain each of the following sections; pause for people to respond.
     Appreciations
     Puzzles
     Complaints with Recommendations
     New Information
     Hopes & Wishes

PMI-ACP Study Notes

If you're studying to become a Project Management Institute Agile Certified Professional (PMI-ACP^®), or intend to take my 3-day public prep class in March, the next few blog entries are for you. Every single question on the ACP exam must be a direct quote from one of the following books:

Agile Retrospectives: Making Good Teams Great by Esther Derby & Diana Larsen
Agile Software Development: The Cooperative Game – 2nd Edition by Alistair Cockburn
The Software Project Manager’s Bridge to Agility by Michele Sliger, Stacia Broderick
Coaching Agile Teams by Lyssa Adkins
Agile Project Management: Creating Innovative Products – 2nd Edition by Jim Highsmith
Becoming Agile... in an imperfect world by Greg Smith, Ahmed Sidky
Agile Estimating and Planning by Mike Cohn
The Art of Agile Development by James Shore
User Stories Applied: For Agile Software Development by MikeCohn
Agile Project Management with Scrum by Ken Schwaber
Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, James R. Trott

Why would you study to become a PMI-ACP^®?

It's a process and framework-agnostic program that touches everything agile, from people & interactions to processes and tools, such as Scrum, XP, Crystal, Lean thinking, and Kanban. Preparation for this exam will help you learn to apply modern product development thinking (as Highsmith puts it, innovation lies at the edge of chaos). It will also help you understand what parts of your job will change, and what will remain the same.

Preparing for the Exam

The PMI has set a high bar before you're permitted to take the 3-hour multiple choice test: 2,000 hours of project management experience, 1,500 (overlapping) hours of agile project experience, and 21 Category A PDUs of Agile Training, as well as other requirements. It's a significant investment as well--PMI fees, classes, and exam fees. Read on at the PMI site.

In my opinion, the greatest way to cram for the exam is by going to AgileExams.com in study mode. They'll help you learn to think like the test authors, and to review tons of content. If you don't have the background to answer the questions, though, you'll need to do some more work. You can read the 11 books, take an online prep course, or a face-to-face course, or you can study an exam prep guide (I recommend Mike Griffith's guide).

If you're looking for more than a certification, though, I want to work with you. I'm running this prep course because I want to help agile practitioners (this is NOT an introductory course) get to the next level in their agile adoption. This 3-day course is designed to help you learn how to apply these concepts at work AND pass the test on day 4, if you're so inclined. About half of my clients have taken the test immediately afterwards; others waited a couple months. In any case, it looks to me like half the people that pass the exam study a couple hours a week for 3 months. I have had experienced practitioners come through my class with no prior preparation and pass immediately afterwards--but if Agile is new to you, or you've been solely in the Scrum world--it will take more time for you to study.

About the Study Notes

This series will highlight key concepts in each of the 11 books--concepts that are likely to show up on the ACP exam. If you've got a copy of the book handy, whenever possible I'll give page numbers so you can read the full context.... so stay tuned!
Here's what's published so far:

• Agile Retrospectives
• Coaching Agile Teams 

Agile Metrics

Overview

There are no “standard” agile metrics, because what's easy to measure tends to distract us, and what's important to measure is hard to quantify.  The most important thing about Agile metrics is that we need to have a clear objective for using them--normally start with a hypothesis that, say, if defect count drops then lead time will go down too. Many of the metrics below would be used for a short period of time and then dropped when the objective is reached.

With that being said, I've seen clients dovetail push-and-pull metrics, like lead-time & defect count, so that they can be used for a longer period of time, and that if someone starts gaming one number they get penalized on the other.

The following may also be useful:

·       Lead Time

·       Defect count (at various phases; what’s a bug?)

·       Work in Progress

·       Code coverage

·       Unplanned Changes

·       Velocity (story points or story count per sprint)

·       Return on investment

·       Innovations per sprint

·       Artifacts generated

·       Slack time

·       Failure Load (firefighting time)

·       Iteration Burn-Down

·       Unfinished Stories

·       Customer Satisfaction

·       LOC (lines of code)

·       Un-deployed Stories

·       # Blocks

·       Budget/Schedule Compliance

·       Flow Efficiency (lead time / touch time)

·       Release Burn-Up

Definitions

Definitions and cross-references for all these metrics follow.

Lead Time

Defined:            Time from “concept to cash”, the total time it takes to develop an idea and sell it to a paying customer.

Caution:             It may be difficult to measure actual lead time, and many teams approximate lead time by capturing the time a request enters the development process and capturing the time it reaches the definition of done. This approximation may be a reasonable place to start measuring, but it may cause micro-optimization (changes that actually detract from corporate goals) or reduce customer discovery (learning what the customer would pay more for)

Side Effects:     If we blindly push this metric to a minimum, we may see:

·       increased defect count

·       reduced code coverage

·       increased failure load

Benefits:           customer satisfaction, flow efficiency, un-deployed stories, work in progress

Defect Count

Defined:            Total count of surprises, unexpected behavior, flaws, and shortcomings of the product identified during or after an iteration demo.

Caution:             Aggressive definitions of “defect” help everyone focus on customer satisfaction; anything short of the definition above will

Side Effects:     If we blindly push this metric to a minimum, we may see:

·       reduced velocity

·       reduced innovation

·       more unfinished stories

·       more blocks

Benefits:           code coverage, unplanned changes, customer satisfaction, lines of code

Work In Progress (WIP)

Defined:            Number of items we are actively working on. The higher the WIP, the more multi-tasking hurts our efficiency.

Caution:             While a WIP limit of 1 per person may seem ideal, research suggests it’s closer to 2 per person in the event a block prevents us from working the highest priority item.

Side effects:     If we blindly decrease this metric, we may see:

·       excessive slack time

Benefits:           lead time, defect count, velocity, ROI, unfinished stories, un-deployed stories, blocks, budget/schedule compliance, flow efficiency

Code Coverage

Defined:            Percentage of production code tested by the automated regression suite.

Caution:             Static and dynamic code coverage evaluation tools cannot tell us if the code just happened to be executed or if it was verified for proper behavior. The only strategy for full coverage of behavior is Test-Driven Design / TDD / BDD. Short of automation, we cannot find regressions fast enough to keep up with development.

Side effects:     If we blindly increase this metric, we may see:

·       increased failure load

·       decreased velocity

·       reduced innovation

Benefits:           lead time, defect count

Unplanned Changes

Defined:            Number of unanticipated change requests we were able to include in this product increment. Since Agile is all about being more responsive, this is a metric that shows how adaptive we’ve become.

Caution:             Tracking this metric could be burdensome—what counts as a change request? A font style change on the UI? An increase in scope? Pick a granularity to track and stick with it.

Side effects:     If we blindly increase this metric, we may see:

·       decreased velocity (churn)

·       excessive innovation (lack of focus)

Benefits:           customer satisfaction, return on investment, lead time

Velocity

Defined:            Abstract quantity of work that can be completed in a given iteration. Velocity automatically accounts for regular meeting overhead and business-as-usual activities. Velocity is often reported in units of Story Points, Ideal Days, Ideal Hours, or Story Count. Story Points tend to encompass effort, doubt & complexity, so they’re packed with more information than a simple estimate.

Caution:             For large organizations, it helps to normalize Story Points on approximately 1 Ideal Day to simplify strategic & roadmap level planning. Story Points should not used to evaluate past performance—they’re only intended for forward planning.

Side effects:     If we blindly increase this metric, we may see:

·       reduced customer satisfaction

·       increased failure load

·       reduced artifacts generated

·       reduced innovation

·       reduced slack time

Benefits:           lead time, budget/schedule compliance, flow efficiency, release burn-up

Return On Investment

Defined:            Percent earnings based on revenue, capital investment and operational cost.

Caution:             Many teams don’t have access to this data, or don’t track it long enough to see the impact of their work on ROI. Yet it’s key to justifying investment in software.

Side effects:     If we blindly increase this metric, we may see:

·       reduced innovation

·       reduced customer satisfaction

·       increased failure load

Benefits:           lead time, budget/schedule compliance

Innovations per sprint

Defined:            As an agile team becomes more cross-functional, the whole team gains a greater appreciation for what the customer finds valuable. When this results in feature ideas that the Product Owner selects for the backlog, we consider this a success of the whole team.

Caution:             Innovation must be customer-centric—in Kano’s terms, either a linear feature or an exciter/delighter.

Side effects:     If we blindly increase this metric, we may see:

·       reduced release burn-up

·       excessive unplanned changes

·       increased lead time

Benefits:           customer satisfaction, return on investment

Artifacts Generated

Defined:            Any document or non-source-code electronic file generated as a result of the software development process is an artifact. We may want to track help files generated to get a sense of whether our development is sustainable.

Caution:             Some artifacts were historically created for visibility into a long development cycle. If you can rely on automated customer tests instead, this type of “executable specification” will be demonstrably current.

Side effects:     If we blindly increase this metric, we may see:

·       increased lead time

·       increased work in progress

·       reduced budget/schedule compliance

Benefits:           n/a

Slack Time

Defined:            Buffer, maintenance, or creative work that is tangentially related to prioritized product backlog items. Just as a highway has serious congestion at 80% utilization, we see software teams loaded above 80% see serious performance bottlenecks.

Caution:             Slack time is not vacation or goofing off. It is one of the only steps in an agile SDLC that consistently reduces technical debt.

Side effects:     If we blindly increase this metric, we may see:

·       reduced velocity

·       more unfinished stories

·       more un-deployed stories

Benefits:           lead time, failure load, innovations per sprint, customer satisfaction

Failure Load

Defined:            Percent of time spent fixing defects. Failure load is waste; it’s forcing our customers to pay for features twice. We want to avoid failure load whenever practical. You can’t go fast without high quality!

Caution:             n/a

Side effects:     If we blindly decrease this metric, we may see:

·       reduced velocity

·       reduced innovation

·       more unfinished stories

·       more blocks

Benefits:           code coverage, unplanned changes, customer satisfaction, lines of code

Iteration Burn-Down

Defined:            Bar chart showing hours or story points remaining per day of the iteration. The trajectory of the bars shows whether we’re on schedule or not.

Caution:             Without small enough stories, teams will see a “clumping” effect where most of the work tends to get finished at the end of the iteration. This is not desirable—find ways to get to done earlier so there is time to make unforeseen adjustments.

Side effects:     If we blindly improve this metric, we may see:

·       increased blocks

Benefits:           unfinished stories, work in progress, return on investment, customer satisfaction, budget/schedule compliance

Unfinished Stories

Defined:            Any story that did not reach the “definition of done” in the same iteration in which it was begun is an unfinished story. A product owner may cancel, re-schedule, split, re-scope, or defer such a story.

Caution:             Unfinished stories come from a lack of discipline. There’s always a way to negotiate a good story so that it can be split or completed this iteration.

Side effects:     If we blindly decrease this metric, we may see:

·       n/a

Benefits:           customer satisfaction, lead time, release burn-up

Customer Satisfaction

Defined:            increased customer retention or increased revenue

Caution:             Learning about customer retention is slow, and we need safe sandboxes in which to experiment and learn more quickly (e.g., pilot markets or beta tests).

Side effects:     If we blindly increase this metric, we may see:

·       reduced innovation

·       reduced slack time

Benefits:           return on investment

Lines of Code (LOC)

Defined:            One source-code line; from an agile perspective, a line of code increases the risk of system failure and increases the cost of maintenance. We seek elegance, clean code, and avoid duplication in the code base.

Caution:             Mature software shouldn’t always grow. At some point, re-factoring will keep the LOC count stable while we continue to add features. At the same time, if we make code difficult to read or understand, we’ll introduce additional risk for system maintainers.

Side effects:     If we blindly decrease this metric, we may see:

·       increased defect count

Benefits:           lead time, failure load

Un-deployed Stories

Defined:            stories that have reached a team’s definition of done but are not yet actually earning money or being used by a customer

Caution:             until a paying customer uses our product increment, there is risk that delivery teams will need to get involved in supporting it

Side effects:     If we blindly decrease this metric, we may see:

·       decreased customer satisfaction (a product that changes too often?)

Benefits:           lead time, defect count, work in progress, unplanned changes, innovations

# Blocks

Defined:            The number of impediments that development teams have asked for help on.

Caution:             A large number of blocks may mean teams aren’t being as proactive as they could be, or they don’t have an adequate “definition of ready” before accepting work.

Side effects:     If we blindly decrease this metric, we may see:

·       unfinished stories

·       undeployed stories

Benefits:           lead time

Budget/Schedule Compliance

Defined:            compare the estimate of a strategic or roadmap level portfolio item with the team-level estimates (for completed stories only)

Caution:             until a product increment is considered deployable (a minimally marketable feature), we cannot make any assessment on its cost

Side effects:     If we blindly optimize this metric, we may see:

·       reduced innovation

·       fewer unplanned changes

·       reduced customer satisfaction

Benefits:           increased return on investment, reduced lead time, reduced work in progress

Flow Efficiency

Defined:            flow efficiency = lead time / touch time; that is, the amount of time to go through the whole system divided by the actual amount of time someone is actively working on it.

Caution:             Flow efficiency highlights wait time in the existing process, though we really need to focus on value added time. Use this to identify red flags but only as a secondary method to value-added optimization.

Side effects:     If we blindly decrease this metric, we may see:

·       excessive slack time

·       excessively limited WIP

Benefits:           lead time, return on investment

Feedback

What's missing? What would you change?