PMI-ACP Study Guide

In this Article:

• WHY TO APPLY FOR PMI-ACP?
• FACTS ABOUT THE PMI-ACP EXAM
• WHAT TO READ & WHAT TOPICS TO FOCUS ON?

PMI Agile Certified Practitioner (PMI-ACP)^sm is the newest credential offered by PMI. It was opened for the public at the 31^st Jan 2012, the same day I passed the examJ.

As all of PMI’s certificates, you should fulfill all the requirements in order to apply for the exam; details can be found here PMI-ACP Handbook

WHY TO APPLY FOR PMI-ACP?

Back to top↑

I can think of lots of reasons why you should apply for PMI-ACP, specially if you are involved in the software industry, but I will list few of them here:

• Offered by PMI, which means it’s recognized and respected worldwide.
• It’s not a methodology specific; it covers more than one Agile methodology (Scrum, XP, Lean, DSDM, FDD,…).
• Agile Project Management practices are booming, and in my opinion they will take over in the coming few years.
• Big Enterprises are adapting Agile Practices, Microsoft for example, check below links
  • MSF for Agile Software Development v5.0
  • MSF for Scrum
  • Visual Studio Scrum 1.0

FACTS ABOUT THE PMI-ACP EXAM:

Back to top↑

• Multiple choice questions
• 120 questions
• 3 hours duration
• Questions Distribution

For more details about the exam structure please check the Examination Content Outline on PMI website.

PMI listed 11 books as reference material for the exam; check the Reference Materials on PMI website, it will take a while to read all of them, so I will be summarizing what you need to read and what you need to focus on.

WHAT TO READ & WHAT TOPICS TO FOCUS ON?

Back to top↑

• Agile Methodologies
  
  • Agile in General : Agile Estimating & Planning by Mike Cohn is highly recommended (I read the entire book), It will give an excellent understanding to:
    • Adaptive planning: Release, Iteration and Daily planning (Progressive elaboration planning).
    • What is velocity, how measure it, and how to use it.
    • Agile estimating techniques (relative sizing, planning poker, who does the estimation).
  • SCRUM: Agile Project Management with Scrum by Ken Schwaber is recommended; INTERNATIONAL SCRUM INSTITUTE website provides a very good material to start with.
    • Understand what is Sprint.
    • Understand the Scrum artifacts such as product backlog and burn down charts; know what they are, why we use them and how to analyze the charts.
    • Understand the Scrum meetings such as Sprint Planning, Daily Scrum, Sprint Review and Retrospective very well. You should know what happens in each of these meetings.
    • Scrum Roles: Understand the roles and responsibilities of the Scrum Master & the Product Owner.
  • Extreme Programming (XP): Art of Agile Development by James Shore’s is recommended.
    • Focus on XP Roles.
    • Understanding the below terms:
      • Test driven development.
      • Continuous Integration.
      • Technical debt.
      • Refactoring.
      • Timeboxing.
      • Root-Cause Analysis (the five Whys).
  • Lean Methodology:
    • Understand the History of Lean and the Lean Software Development Principles.
    • What is Lean Portfolio Management and what is the value of it to the organization?
    • Value Stream Mapping.
    • Understand the basics of Kanban.
    • What is Work In Progress (WIP)? What’s the benefit of limiting the WIP?
    • below articles are recommended:
      • Kanban For Software Engineering by David Joyce.
      • Lean Software Development by Dasari. Ravi Kumar.
      • Lean Software Development by Andre van der Schyff.
• Agile Risk Management: The Software Project Manager’s Bridge to Agility by Michele Sliger (Chapter 11).
  • Risk Burndown Charts: Understand what they are, their overall purpose and how to analyze them.
  • Risk Audit Meeting: What is this about and when does it happen during iteration?
  • Agile Qualitative vs. Quantitative Risk Analysis: How would we compare
  • Agile risk analysis to traditional? What is the difference between these two methods?
• Communications Management: The Software Project Manager’s Bridge to Agility by Michele Sliger (Chapter 10).
  • Stakeholder Management: Setting clear expectations from the very start with your stakeholders on what information they need, how and when they should engage with the team and how frequently (time commitment needed for success), how do we communicate changes in scope/time/schedule to them, how do we communicate project risk.
  • Planning: Identifying who you need to communicate to (Team members, Sponsor, Stakeholders) and what you need to communicate to them (Project and Team Charters, Release Plan, Iteration planning, daily standup, demo and retrospective meeting dates/location, team velocity, team task board or team room location, project portal site ..etc)
  • Performance Reporting and Visible Information Radiators: Understanding what information radiators are all about and why we use them, how to leverage their power even for distributed teams, how we track and report performance through burn up/burn down charts at the iteration level and at the release level. How we can analyze the various charts and understand if things are going well or not and respond quickly to what we’re seeing.
  • Osmotic Communication: Alistair Cockburn (author of Agile Software Development – The Cooperative Game) describes this as the information that flows in the background hearing of teams that are co-located so they pick up relevant information, as though by osmosis. When someone asks questions then others can tune in or out and contribute to the conversation. This is an example of rapid and rich feedback that has high value with little structure. It can help the team identify and address errors, issues and risks early on the project.
• Servant Leadership: Coaching Agile Teams by Lyssa Adkins
  • Leaders understand that their role is to empower the team, help them make their own decisions, help them become self-organizing and not use command and control to direct them. This is the hardest transition initially for traditional project managers (and leaders) if they were used to a command and control style of managing.
  • The focus of servant leaders is the growth and empowerment of the people instead of the management of the tasks. Learn how you can transition to being the team’s coach, mentor and facilitator instead of their problem solver.
• Project and Quality Standards:
  • Quality is collectively owned by the team and no longer the sole responsibility of the testing team. The testers, analysts and developers all collaborate early on to define the quality measures for their project.
  • Quality planning in Agile happens as part of the team’s Release Planning, Iteration Planning and daily planning activities.
  • The team along with the product owner develops their ‘Definition of Done’ that provides clear guidance for when a ‘story’ is done. This could also be defined at various other levels, for example we could have a ‘Release definition of Done’ and a ‘Project definition of Done’. The story definition of Done would contain the product owner’s expectations for quality and the team’s standards.
• Earn Value Management, below articles are recommended:
  • Earned Value For Agile Projects by John Rusk.
  • Agile EVM by Tamara Sulaiman.
  • Earned Value and Agile Reporting by Mike Griffiths.
• Business Case Development:
  
  • I think what is needed to understand here is how an Agile business case may differ from traditional business case development. An Agile Business Case could still be born during the traditional ‘Initiation’ phase which may also be referred to as ‘Visioning’ or ‘Feasibility’ in Agile and needs to have ‘Just Enough’ or ‘Barely Sufficient’ analysis as Alistair Cockburn would say.
    
  • An Agile business case may use techniques such as ‘Design the Box’ for defining the vision and objectives and should also include very clear conditions of satisfaction and measures for success (also called Project Level Definition of Done).
    
  • High level requirements, a high level roadmap along with high level estimates could be submitted with the knowledge that after execution of a few iterations these estimates will be continuously updated to reflect the team’s new knowledge and actual velocity.
    
• Innovation Games:
  
  • You should know what innovation games are about (created by Luke Hohmann), why we use them and know the top ones such as Product Box (used during visioning) and Buy a Feature (used for prioritizing).
    

I hope that this article helps you for your exam preparation.

Special thanks to Mr. Mohamed Khalifa Hassan, who helped me in my exam preparation.

References: PMI Website