PMI-ACP Study Notes: Agile Planning

PMI-ACP Study notes - Agile Planning

[PMI-ACP® Exam Study Notes] After having obtained the project charter, the customer / Product Owner and the team would be engaged in the planning for the Agile project. Agile planning deals with project organization, planning, management, communications and continuous management. Though it is often said that Agile projects emphasis on responding to changes rather than planning, a right amount of planning is required for the projects to kick off successful.

Article Highlights

Stakeholder Identification

  • Stakeholders are anyone with an interest in the project (can be positive or negative).
  • For Agile projects, the project team and the customer are NOT considered as stakeholders (in traditional project management and according to the PMBOK® Guide, stakeholders include the project team but not the project manager).
  • The customer / Product Owner would try to understand the needs (including communication needs) of the stakeholders and bring their views into the project.
  • The stakeholder registry would include barely sufficient information about the individual stakeholder group’s support level, preferences, etc.

Agile Project Analysis (Initial and Continuous)

  • Agile teams do need to carry out analysis and planning at the beginning of the project (often termed as Iteration 0) and during the project (retrospectives, etc.)
  • The project team would discuss in depth about problems and wants of the customer through face-to-face communication, often with the help of some tools and techniques (many are similar to what are described in the PMBOK® Guide):
    • Brainstorming – everyone to voice out their opinions without immediate judgement
    • Innovation games – games are used to engage the team members and customer, e.g. 20/20 Vision, the Apprentice, Buy a Feature, Product Box, Prune the Product Tree (reference: Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann).
    • Parking lot chart – a piece of paper to put important but off-topic issues / queries for later investigation / discussion, e.g. in requirement gathering
  • Agile Analysis Concepts
    • Value Stream Mapping – inspired by Lean Manufacturing, this is the method to analyze the processes to eliminate wastes
    • Root cause analysis – with cause and effect diagrams (Ishikawa / fishbone diagrams), “five whys”
    • Force field analysis – to understand the forces for and against a change

Agile Planning

  • The accuracy of estimation will improve over time on a project in the form of “Cone of Uncertainty” (25%-400% from the very beginning to within several percentage near complete)
  • Agile Planning Artifacts and Meetings
    • The Product Vision Statement is developed by the Product Owner (with the help of the team) as an elevator statement on the purpose of the product
    • The Product Roadmap tells the about the schedule and cost milestones – an overview of the planned releases of the project, the Product Roadmap will change over time
    • Personas – realistic depiction of likely users for the product, can be real or fictitious
    • Wireframes – as a sketch graphical presentation of how the requirements are fulfilled, as a kind of requirement documentation
    • Release Plan – responsible by the customer / Product Owner with the help of project team in release planning to indicate the availability dates for features, subject to changes depending on actual progress / change requests
  • Agile Planning Terms
    • Agile Themes – a theme for an iteration for grouping similar functions to be done in a batch, e.g. bug fix, reporting, etc.
    • Epic Story – a large block of functionality (spanning several iterations) – will later be disaggregated into user stories for implementation
    • User Story – taking the format of “As a [role], I want [need] so that [business value]” to describe the requirements in real world scenarios, often written on Story Cards
      • [INVEST] Independent, Negotiable (can be discussed on implementation), Valuable, Estimatable (adequate info), Small, Testable
      • [Ron Jeffries’ three Cs of user story] Card, Conversation, Confirmation
    • Story Maps – an overview of how individual user stories are related to each other
    • Features – a capabilities / group of functionalities that is of value to the end user
    • Minimal Marketable Feature (MMF) – the smallest group of functionality that can offer value to the end user, can be put into production once finished but depending on the decision of the Product Owner / customer
    • Tasks – the underlying actions / development work to be taken to finish a user story, tasks are taken up by the team through self-organization
  • Agile Planning Concepts
    • Progressive Elaboration – knowledge about the product and requirements will be clearer as the time goes by, those will be revisited and refined continually
    • Rolling Wave Planning – break down the planning into stages, with the near-time planning to be carried out first
    • Definition of Done – this is a written consensus of what are considered “Done” of the whole team (including the customer)
    • Timeboxing – to combat “Pakinson’s Law” by introducing a fixed deadline for tasks/meetings in order to enhance efficiency

Agile Estimation

  • Agile Estimation Concepts, Tools and Techniques
    • Relative Sizing – traditional project management would estimate in terms of money and time, but in Agile project relative sizing (e.g. story points) will be used as Agile projects are more prone to changes and thus it is not meaningful to estimate in exact units
    • Ideal Time – a block of uninterrupted period to focus solely on the task without distractions of others/tasks/routine, etc. for estimation (though not realistic in real world)
    • Wideband Delphi Estimating – allow discussion of details of the requirements first and then each individual would try give an estimate for the user stories, etc. with relative sizing, repeat until a consensus is reached
    • Planning Poker – each members select from a deck of cards (with ?, 0, 1, 2, 3, 5 …) the story points for a user story, discuss to reach a consensus
    • Affinity Estimating – assign a size (e.g. S, M, L, XL, XXL) to user stories


This piece of PMI-ACP® Exam study notes describes the tools and techniques, artifacts and concepts for Agile Planning and Estimation. Though Agile is often considered to be low on planning, planning is very important for Agile projects and the actual Agile planning scattered over the whole project duration.

Most Popular PMI-ACP Certification Articles

Support website running for FREE, thanks!

If you find this post helpful and if you are thinking of buying from Amazon, please support the running cost of this website at no extra cost to you by searching and buying through the search box below. Thank you very much for your help!

Edward Chung

Edward Chung aspires to become a full-stack web developer and project manager. In the quest to become a more competent professional, Edward studied for and passed the PMP Certification, ITIL v3 Foundation Certification, PMI-ACP Certification and Zend PHP Certification. Edward shares his certification experience and resources here in the hope of helping others who are pursuing these certification exams to achieve exam success.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

4 Responses

  1. Mzwakhe says:

    Hi Edward. Thank you for your website and articles. Really informative.

    I have noticed that different people have different views as to whether the project team is considered to be part of the stakeholders on Agile projects or not.

    I am 3 days away from writing my PMI-ACP exam. I am stuck on approaching the exam with the view that the project team is a category of stakeholder to be treated in its own way, similarly to how you would communicate to Suppliers and Management differently?

    • Sorry I don’t have the answer either. As that really depends on how the project manager’s view, maybe the exam won’t ask you about this. Anyway, wish you success!

  2. Greg Petrov says:

    Hi Edward!
    Thanks for your exciting articles.
    One question is: it looks like PMBOK Project Charter is similar to Agile Product Vision Statement. But Project Charter is an output of Initiation stage. So should we move Product Vision Statement to the same stage?
    Thank you.

    • Hi Greg,

      Thanks for your comment. Yes, the Project Charter and Agile Product Vision Statement bear some resemblances. Yet, the Project Charter is quite a detailed formal document for the project while the Product Vision Statement is just an “elevator statement” (very brief and concise) on the purpose of the product without touching on the authorization of the project.

      So, they are actual not the same for the purpose of project administration.

      Wish you PMI-ACP success!