PMI-ACP Exam Tips

Actually... Don't Click Me.

We at AgileScout received a cool email about tips from someone who recently took the PMI-ACP Exam, see the details below!

[See my experience with the PMI-ACP here]

“I took the PMI-ACP certification examination on 6th October in Chicago.”
My overall experience of taking this exam is as follows:

  1. Time: The 3 hours to answer 120 questions were sufficient. I finished answering all questions in 2 hours. There were 4-5 questions which were not very clear and another 10-12 questions I marked for “review” later. I used my extra time to review those Marked questions to guess best answer PMI may be expecting.
  2. Agile Practices: There were multiple questions on SCRUM and XP, very few questions on Kanban and Lean, almost none on Crystal, FDD, and DSDM.
  3. Roles: Fully Understand the Roles in SCRUM and XP, what are the responsibilities carried by those roles, various meetings, input and outcome of those meetings like review, retrospective etc,
  4. Scenario Based Questions: There were multiple questions based on scenarios and how best will you apply Agile practices under those scenarios.
  5. Understand the difference between terms of coordination, collaboration and communication. Multiple questions on team Collaboration.
  6. Surprise questions on Agile Portfolio Management.
  7. Multiple questions on Agile Risk Management.
  8. Multiple questions on Story Points, Burn-down Charts and Velocity calculations.

Overall PMI ACP certification exam is challenging and tests the knowledge of Agile Manifesto, Agile Principles, Agile Practices, and Agile Methodologies very well. If you read the PMI suggested material, PMI suggested books, I am sure you will PASS the certification examination with flying colors!!

[Thanks Vivek!]

*It has come to our attention that this was forwarded from someone who had received an email update from William Fumey of Sorry for the repost!

18 Replies to “PMI-ACP Exam Tips”

  1. This is pretty much what I was afraid of the PMI doing: Basically, you come out of that exam with knowledge of a certified amount of agile trivia, which is going to be “taken to the bank” by business as agile bona fides.

    Canary in the coalmine, my friends, canary in the coalmine.

        1. Who do you want to audit your company’s books – a CPA, or someone who says he’s been auditing for ten years, but doesn’t believe in testing because all it does is determine whether you’ve mastered a bunch of trivia? Does such an assertion make him better qualified than a CPA? As qualified? Do you and your team have the time to interview him to find out?

          Hiring managers get a whole lot of resumes, and they want a way to filter out those who aren’t worth interviewing. Credentials like PMP, for better or worse, are used as filters. When PMI announced their PMI-ACP pilot program, they justified the investment on their part with the results of a survey that indicated managers saw value in such a credential.

          Will it absolutely identify the best practitioners? Of course not, and no one says it will. But Agile is becoming mainstream, and Agile experience will soon be seen as a commodity, like accountants and project managers. At some point, there will be enough PMI-ACP credential holders out there that many hiring managers won’t bother to interview an otherwise unknown applicant who doesn’t have one, even one with early adopter cred.

  2. Pingback: PMI-ACP Exam Tips | Agile | Syngu
  3. And that’s the canary.

    This is precisely what killed the value of the Novell, Cisco, HP and Microsoft certification exams when they were used as a proxy for experience: They become a commodity that spawned a major cottage industry of informants who would “leak” questions out to build “practice exams” that were then sold to applicants desperate to gain the accreditation to pump-up their resumes and out-compete other applicants.

    The result? A deluge of “paper-qualified” applicants flooding the market that diluted the value of the accreditation, ironically leaving business in the same predicament as they were before: With no way to sort out the wheat from the chaff.

    This problem has occurred in the Scrum community as well, with the proliferation of Certified Scrum Practitioner courses that contributed to accrediting tens of thousands of Scrum Masters, a good portion of whom didn’t understand fundamental concepts like developing in incremental iterations.[1]

    As a holder of three Scrum certifications, I see them all in their context: Basic assessments of knowledge I already possessed after years of experience that could be easily “gamed” by anyone. In talks that I have with my customers, I caution them to never hire based on the number of letters strung after an applicant’s name, but their experience and attitude. It takes more effort, but that’s what the proliferation of certifications has done.


    1. How much experience do you need to be “qualified?” Is ten years of experience developing in Java using Scrum more valuable than two years? Five times as valuable? Might that ten years actually be two years of experience, five times?

      The only sure fire way to know if a developer can do the job is to put him/her to work, and that’s just too damned expensive. So hiring managers, who have to assess risks and make decisions, use proxies like credentials, education, and yes, experience. Personal recommendations trump everything, but you can’t always get them, can you?

      The real world is less than perfect, but it’s the one we develop (and manage) for.

      1. “The real world is less than perfect, but it’s the one we develop (and manage) for.”

        Precisely. Working with agile practices isn’t easy: It’s hard work that takes a lot of effort to pay good dividends. Why should we expect less from the hiring process to create high-performing agile teams?

        I advocate to my customers exactly what you dismiss: Test-driving candidates to see if they fit the organization and perform to expectations. It’s only through empiricism – that stalwart principle of agile – that we can accurately assess if we can get ROI. Using certifications as a proxy for this “hard work” is no better than putting faith in an untested Big Design Up Front plan and riding it to an unpredictable conclusion several months later. You could be right – or incredibly wrong.

        For established teams, it’s about self-selection: They need to have a say in vetting who is joining the team and if they will fit the team dynamics, understanding that no-one is 100% and will need to be brought along to a certain extent. This follows what Ralph Stayer advocates in his essay, “How I Learned to Let my Workers Lead” [1] which relates the transformation of his company when agile practices weren’t even on the radar (1985):

        “We offered to help them set performance standards and to coach them in confronting poor performers, but we insisted that since they were the production-performance experts, it was up to them to deal with the situation. I bit my tongue time and time again, but they took on the responsibility for dealing with performance problems and actually fired individuals who wouldn’t perform up to the standards of their teams.

        This led to a dramatic change in Johnsonville’s human resource system. Convinced that inadequate selection and training of new workers caused performance problems, line workers asked to do the selection and training themselves. Managers helped them set up selection and training procedures, but production workers made them work.

        Eventually, line workers assumed most of the traditional personnel functions.”

        For Scrum Masters or Coaches, you absolutely need to test-drive them because they each have a different style. A certification won’t help with this, nor will a 30-60 minute interview. Agile isn’t an off-the-shelf installable product (a side-effect that certification programs engender). The test drive can be based on a mock-project with a team for a day to several iterations or more on a real project. The emphasis that is now placed on cert-first vetting needs to move more toward the empirical approach advocated by Eric Ries: Build-Measure-Learn.

        In the end, the calculus is on the business: Trust the devalued cert that everyone and their dog has and risk a candidate that could cost more in damages than they’re worth or invest in a smart selection process to empirically validate their bona fides? Personally, I’ve seen more of the former and had teams that the business was absolutely dumbfounded as to how they could not perform up to expectations – it’s a rather obvious outcome, IMHO.


        1. Johnsonville Foods is a small, family-owned business located in a small town outside Sheboygan, WI that primarily makes sausages, and the line workers referenced were hourly production line folks. I would suggest that there are significant differences between knowledge workers tasked with creating software and sausage production line workers, and best practices for recruiting and selecting them. I would also suggest that there are significant differences between a small, privately-held company and a publicly traded corporation, including but not limited to human resources and compensation practices.

          If you’ve never posted a requisition on a national job board, it’s easy to get inundated with resumes. The challenge is to choose a small number of candidates to interview, and not throw wheat out with the chaff. Note that after interviewing four candidates for the same position, most non-professional interviewers have difficulty telling them apart, so you really don’t want to dump seventy resumes on the table and tell the team to choose their new colleague.

          Like software development, recruiting is a non-trivial activity, requiring some specialized skills. It’s good to give the team a say, but in most cases it’s counterproductive to give them responsibility for the process, as well as the outcome. Especially if you expect them to do their regular jobs at the same time.

          1. “I would suggest that there are significant differences between knowledge workers tasked with creating software and sausage production line workers, and best practices for recruiting and selecting them.”

            Given our industry’s high failure rates, I’d say there’s a high affinity between creating software and sausage.[1] However, again in your haughty dismissal of the Johnsonville scenario you’ve failed to take the core lesson out of it: If line workers could take responsibility for vetting new team members or self-selecting out poor performers, why would this be beyond an agile development team? What would better qualify someone who is far-removed from the team and doesn’t know them to select candidates? Is it the purpose of an IT department to run a very expensive daycare? Certainly that is the prevailing thinking I’ve seen over my experience as a developer and coach.

            If you read the entire essay, you’d have realized that the problems Ralph Stayer described are not closely aligned with the challenges businesses still face today (eg. why command & control structures don’t perform as well as teams that are empowered to make decisions). In fact, there’s a great deal of affinity between Stayer’s observations about team dynamics and those that Takeuchi & Nonaka made around the same time in their Harvard Business Review paper, The New New Development Game which, I am sure you know, is *the* touchstone for all agile and lean practices we have today.

            (I wonder if that warrants a question or two on a PMI-sanctioned exam?)

            I think from your comments so far you have a really rigid, closed mind about a good many things, least of all agile practices – and that’s really too bad. Really good for writing a multiple choice exam and getting “certified” (ie. the assurance that there is a right/wrong answer to everything), but not so good for the challenges we face in IT/software projects that require fresh, creative approaches and challenges to status quo thinking.


          2. Well said Chris. I like your “expensive daycare” comment. I think I’ll use that… 🙂

            I completely agree with you here. We need to hire “problem solvers” not factory workers.

            Problem solvers will help companies create innovative, creative, and valuable software. Hiring managers need to hire great problem solvers.

          3. Really like your comment here Dave.
            Here is my single idea around hiring talent.
            “Would you not want to hire the best?”

            As such, paper can help ‘filter’ applicants… but it would be valuable to do your diligence around those that do (not have the paper).

            Those potential employees that do not have ‘paper’ might just be the best damn employee you’ve got.

            Case in point: I worked as the Program Manager of a multi million dollar DoD project. There was a Sr. Architect that was brought on and he had no college degree. He was almost 60, but was the best damn SOA architect I’ve ever met. You would never have guessed that he built himself from a lumber yard worker to a Sr. Technical Architect on a high profile DoD project.

            Now… as the contract ended he wanted to move on to more Program Management work… oops. Wrong career choice. Because he didn’t have ‘paper’ he could not find a company that would allow that type of move.

            Sit down with this guy and you’ll find he’s a rockstar. Sad really.

          4. Chris, if you interpret my rejection of your nicely-cited Johnsonville reference as evidence of “a really rigid, closed mind,” then I don’t think I want you on my team. Social skills are important, and one of the most important social skills in any work environment is the ability to disagree amicably, without casting aspersions.

            Peter, I think everyone wants to hire the best. Your former colleague needs to rely on his network for recommendations, so he’s not an unknown. What’s in dispute is how to filter the resumes from unknown persons in an efficient and cost-effective way. Decision making in the face of uncertainty needs to be influenced by the incremental cost of becoming more certain, compared to the incremental value of that certainty. At some point, you simply have to decide – that’s what leaders do.

Leave a Reply