PMI-ACP Exam Last Minute Study Notes

The most important knowledge and facts for the PMI-ACP® Exam are listed below. This post intends to serve as a last minute study notes for PMI-ACP® candidates to study right before the PMI-ACP® Exam. The notes here are short and concise, with little or no explanations. If you would like to get more detailed elaborations on the topics, please click on the links in the headings of each section.

General Agile Principles

Agile Manifesto

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

12 Agile Manifesto Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Declaration of Interdependence

Agile and adaptive approaches for linking people, projects and value, with focus on Agile Leaders. To achieve these results

1. We increase return on investment by making continuous flow of value our focus.
2. We deliver reliable results by engaging customers in frequent interactions and shared ownership.
3. We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
4. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
5. We expect uncertainty through group accountability for results and shared responsibility for team effectiveness.
6. We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Agile Terms and Concepts

• Agile is best suited to projects with complex requirements and technology
• Agile project scope is not fixed while time and costs are fixed
• Agile uses top-down estimation
• Agile documentation are usually barely sufficient
• Agile favors adaptation while traditional management methods favor anticipation

• Agile Earned Value Management (EVM) should better be applied at iteration level
• Active listening – listening skill progress through the following steps:
  • Internal Listening (how will this affect me)
  • Focused Listening (what are they really trying to say)
  • Global Listening (take note of signs other than what has been said)
• Adaptive Leadership – leaders must adapt to the situation to lead most effectively
• Agile Games (Collaborative and Innovation Games)
  • Remember the future: game for vision-setting and requirements-elicitation
  • Prune the product tree: game to help gather and shape requirement
  • Speedboat/ Sail boat: game to identify threat and opportunities (forces) for the product
  • Buy a feature: game for prioritization
  • Bank-for-the-Buck: game to look at value vs cost
  • Product Box (Vision Box): game to design a fictitious box of the product (to capture top 3 things project must deliver) for prioritization
• Agile Modeling – to capture the intent of the design in a barely sufficient way
• Architectural Spike – a special kind of spike to investigate technological setup
• Burn Rate – the labour (the largest portion) and other costs for each iteration, used in budget preparation or EVM
• Caves and Commons
  • Commons: the common working space organized to maximize osmotic communication
  • Caves: semi-private space to do e-mail, make phone calls, etc. not to be disturbed by others
• Conflict Levels [Lea’s Conflict Model]
  1. Problem to Solve
  2. Disagreement
  3. Contest
  4. Crusade
  5. World War
• Constructive cost Model (COCOMO) – reverse engineering the inputs from completed software projects that had known exact costs to make estimation for the new project
• Cumulative Flow Diagram (CFD) – a burn down chart tracking all activities which can highlight delays and queue sizes
• Cycle Time – the time taken to turn the requirement into production
• Decision Spectrum (by Jim Highsmith) – a participatory decision making tool to allow people to indicate support/reservation for decision
• DRY (don’t repeat yourself) – a programming philosophy asking the programmer not to repeat the same code
• Empirical Process Control – (esp. used in Scrum) decisions about the project are made based on the ongoing observation and experimentation during the project execution rather than on planning upfront
• Epic Story – epic stories are large user story that can be disaggregated into smaller user stories, to be found at the bottom of product backlog
• Escaped Defect – A problem or error that was found by the customer, i.e. escaped the validation, verification and acceptance tests
• Extreme Persona – persona taken to the extreme in order to identify user stories which would be missed otherwise
• Face to face communication is most effective (also known as high bandwidth communication)
• Failure Modes [by Alistair Cockburn]
  1. Making mistakes
  2. Preferring to fail conservatively
  3. Inventing rather than researching
  4. Being creatures of habit
  5. Being inconsistent.
• Feature Buffer – used to manage risk so as to ensure MUST-have features can be delivered
• Generalized Specialist – generalized specialist are BEST fit for Agile teams as Agile team members are required to be cross-functional
• Ground Rules – rules defined by the ScrumMaster / Coach with consensus with the Team that everyone must obey
• Hardening Iteration (Iteration H) – the last iteration to prepare the product for production, often involves final testing, administration, documentation
• IKIWISI (I know it when I see it) – this is typical of ordinary customers, they need to get in touch of the product in order to understand their requirements
• Information Radiator – highly visible charts and figures displaying project progress and status, e.g. Kanban boards, burn-down charts
• Iteration Zero (Iteration 0) – the iteration before iteration 1, used to create Charter, solicit requirements or investigate technological setup
• Kano Analysis: It’s a prioritization technique, it classifies the customer preferences in 4 categories
  • Exciters/ Delighters – bring most values
  • Satisfiers – bring values
  • Dis-satisfiers – cause pain if not present
  • Indifferent
• Lean Portfolio Management – the approach for selecting projects to maximize return on investment
  • portfolio should consist of minimum marketable features (MMF) to allow quick delivery
  • minimize work-in-process
• Minimal Marketable Features (MMF)
  • the smallest feature set that provides value to the end user
• Osmotic Communication – picking up useful information unintentionally by overhearing conversations between others, often happen in collocated teams
• Pareto Principle – also known as 80–20 rule states that, for Agile projects, 80% of the most useful features can be completed in 20% of effort, it is highly advisable to focus on the “20%”
• Participatory Design – an approach to design by actively involving stakeholders in the design process to ensure that the result meets the expectation
• Personas – a representation of a typical group of intended users of the product
• Project Charter is important both for Agile and traditional projects and must be created at the beginning of Agile projects, though the Charter can be barely sufficient
• Project Data Sheet (PDS) – is a single page summary of all key business and quality objectives, product capabilities and project management information including milestones, risks, etc.
• Product Roadmap – provides a high level overview of release milestone of features
• Refactoring – improve code quality without changing behavior or efficiency
• Release Planning Outputs are
  • Release plan
  • Release backlog
  • Actions / action items
  • Risk
  • Assumptions
  • Dependencies
• Risk burn-down chart – shows the change of risk severities over time, risk often drops as the project progress
• Risk Severity = Risk Probability * Risk Impact
• Spike – a spike is a technical investigation used to reduce risks by failing fast
• Story Maps – shows how the users stories / epics are included in each release categorized by:
  • Backbone: essential functionality
  • Walking Skeleton: smallest feature set that work
  • Additional Features: other features
• Tacit Knowledge – is undocumented information and knowledge of the project that cannot / is difficult to transfer to another person by means of writing it down or verbalizing it
• Team Formation Phases
  1. Forming [Leadership Style: Directing]
  2. Storming [Leadership Style: Coaching]
  3. Norming [Leadership Style: Supporting]
  4. Performing [Leadership Style: Delegating]
  5. Adjourning
• Technical Debt – Consists of deficiencies in the code, technical documentation, development environments, 3rd-party tools, and development practices, which makes the code hard for the team to change
  • Paying down technical debt by simplifying or optimizing design improves productivity hence increases velocity
  • In theory, XP projects would not have technical debts as refactoring is built in
• Three-step intervention method for Agile conflicts
  1. Have you shared your concerns and feelings about this with _________?
  2. _______ should know of your concerns. Would it help if I go with you?
  3. May I tell _________ that you have these concerns?
• Triangulation – user stories can be estimated by defining several stories (of various sizes) as the baseline
• User Story – this is a high-level objective of the specific requirement, often in the form of Role [As a …] Function [I want to …] Benefit [So that…], should have the INVEST quality:
  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable
• Velocity – a measure of the speed of the team (in number of story points per iteration), used to create the project schedule in iteration planning
• Wideband Delphi – a method for generating estimates involving greater interaction and communication between participants than the traditional Delphi method
• Work in Progress (WIP) – too much WIP will lower the efficiency as more rework may be needed
  • Little’s Law: the cycle time is directly proportional to amount of WIP

Popular Agile Methodologies for the PMI-ACP® Exam

1) Scrum

• Three Pillars of Scrum
  • Transparency (or Visibility)
  • Inspection
  • Adaptation
• Scrum Roles
  • Product Owner – client representative
  • ScrumMaster – acts a servant leader to remove impediments and assist the team
  • Development Team (Developers)
• Scrum Artifacts
  • Product Backlog – a list of requirements for the product ordered by priority, responsible by the Product Owner
  • Sprint Backlog – a set of requirements for a sprint which are broken down into tasks, maintained by the Team
• Scrum Ceremonies
  • Release Planning [timedboxed: 8 hour;twice a year]
  • Sprint Planning [timedboxed: 8 hour] – each Scrum Cycle starts in the middle of sprint planning meeting (normally, Sprint planning meetings are divided into 2 four-hour sessions in which the second part is for the Team to discuss the tasks involved)
  • Daily Standup [timedboxed: 15 minutes] – 3 questions: 1) What has been done since last meeting? 2) What will be done by next meeting? 3) Any roadblock / impediments encountered?
  • Sprint Review [timedboxed: 2 hour] – product demo and endorsement by Product Owner
  • Sprint Retrospective [timedboxed: 4 hour] – the team reflect on the product and the process for look for improvement opportunities

2) Extreme Programming (XP)

• Extreme Programming (XP) Values
  • Communication – maintain close communication between customer and developers
  • Simplicity – make the design simple for easy understanding and efficiency
  • Feedback – provides timely and constant feedback by information radiators, automated testing tools, etc.
  • Courage – courage to try new approaches / make changes, even if it fails eventually
  • Respect – respect each other
  • Safety
  • Security
  • Predictability
  • Quality of life
• Extreme Programming (XP) Principles – to bridge values and practices
• Extreme Programming (XP) Practices
  1. Whole Team
  2. Sustainable Pace – 40 Hour work week
  3. Pair Programming – two developers sitting together at a workstation, one to code, one to observe
  4. User Stories
  5. Continuous Integration
  6. Test-First Programming
  7. Trust
  8. Rhythm: Test -> code -> refactor -> done
  9. Collective Code Ownership
  10. Coding Standards
  11. Planning Games
• XP Roles  – roles are not fixed, encourage cross-functional team members (up to 12 members in a team)
  • Coach
  • Customer
  • Developers
  • Testers
  • (others as necessary)

3) Feature Driven Development (FDD)

• FDD Practices:
  • Domain object modeling
  • Develop (design, code and deploy) by feature
  • Individual class/code ownership – opposed to the collective code ownership of XP
  • Feature teams
  • Inspection
  • Configuration management system
  • Regular builds
  • Visibility of progress and results

4) Dynamic Systems Development Method (DSDM)

• DSDM  Principles:
  • Focus on business need
  • Deliver on the time
  • Collaborate
  • Never compromise quality
  • Build incrementally from firm foundation
  • Develop iteratively
  • Communicate continuously and clearly
  • Demonstrate control

5) Crystal Family Methods

• Crystal Principles:
  • Frequent delivery
  • Reflective improvement.
  • Osmotic communication
  • Personal safety
  • Focus
  • Easy access to expert users
  • Technical environment

6) Lean Software Development

• Lean Principles
  • Eliminate waste
    • waste is anything that does not add value or any delay that keeps customer from getting value
      • “churn” / “requirement churn” – big form of waste
      • 20% of code delivers 80% of value
      • multitasking is waste
  • Build quality/integrity in
  • Amplify learning
  • Defer commitment as late as possible
  • Deliver fast
  • Empower team – most errors are caused by system failure (not by people)
  • See / Optimize the whole
• Lean Practices
  • Seeing waste
  • Value stream mapping
  • Set-based development
  • Pull system
  • Queuing theory
  • Motivations
  • Measurements
• Seven Software Related Wastes:
  1. Partially Done Work
  2. Extra Processes
  3. Extra Features
  4. Waiting
  5. Motion
  6. Task switching: e.g. Multi-Tasking or working on multiple projects
  7. Defects

7) Kanban

• Kanban Principles
  • Visualize the flow
  • Limit WIP
  • Manage flow
  • Make process policies explicit
  • Improve collaboratively
• Kanban board is an effective information radiator
• Kanban is a pull-based system

8) Acceptance Test Driven Development (ATDD)

• ATDD is a practice in which the whole team collaboratively discusses acceptance criteria for a feature and then distills the criteria into a set of concrete acceptance tests before development begins
• Red – Green – Refactor flow