PMI-ACP Tools and Techniques: Agile Risk Management


PMI-ACP Exam Risk Management

[PMI-ACP® Exam Study Notes] Agile Risk Management is one of the ten Tools and Techniques for the PMI-ACP® exam. The “Tools and Techniques” accounts for a total of 50% of all the questions to be found on the exam paper. According to the PMI-ACP® exam content outline, Risk Management includes Risk Adjusted Backlog, Risk Burn Down Graphs and Risk-based Spike.

PMI-ACP® Exam Importance: around 3-6 questions (~5% of all questions)

Article Highlights

PMI-ACP® Tools and Techniques: Risk Management

  • Risk is uncertainty that could affect the success/failure of the project
  • Risks can be threats or opportunities, negative project risks are considered as “anti-value”
  • In order to maximize values, negative risks must be minimized while positive risks should be utilized
  • Risks identification should involve the customer, project team and all relevant stakeholders
  • Five Core Risks mentioned in the book “The Software Project Manager’s Bridge to Agility”
    • productivity variation (difference between planned and actual performance)
    • scope creep (considerable additional requirements beyond initial agreement)
    • specification breakdown (lack of stakeholder consensus on requirements)
    • intrinsic schedule flaw (poor estimates of task durations)
    • personnel loss (the loss of human resources)
  • Risks are assessed by risk probability (how likely it occurs) and risk impact (how severe the risk impact is):
    • Risk Severity = Risk Probability x Risk Impact
    • Risk probability can be a percentage value or a number on a relative scale (the higher the more likely)
    • Risk impact can be dollar value or a number on a relative scale (the higher the more costly to fix)
  • As a general rule, ‘riskier’ features (with high values) should be tested in earlier sprints to allow the project to “fail fast” as failing during the earlier phrase of the project is much less costly than failing during a later phrase
  • Risk is high at the beginning of the project (both for traditional and Agile projects) but Agile projects have higher success rates as the very nature of Agile project management tends to reduce risks as changes are inherent to the projects
  • Risk can be categorized into the following:
    • Business – related to business value
    • Technical – about technology use and/or skill sets
    • Logistic – related to schedule, funding, staffing, etc.
    • Others – Political, Environmental, Societal, Technological, Legal or Economic (PESTLE)
  • To tackle risks: Identify Risks -> Assess Qualitatively and Quantitatively  -> Plan Response -> Carry Out Responses Should Risks Arise -> Control and Review
  • Risk Adjusted Backlog
    • Prioritization criteria for backlog: value, knowledge, uncertainty, risk
    • Backlog can be re-prioritized by customers as needed to reduce risks while still realizing values
      • The customer can give each feature / risk response actions (non-functional requirements) on the backlog a value by, for features, assessing ROV and, for the case of risks, the costs involved (by multiplying the probability of the risk in %)
      • The backlog of features and risk response activities can then be prioritized based on the dollar values
    • Risk adjustment tries to identify and mitigate the risk at an early stage of development
    • ‘Fail fast’ allows the team to learn and adjust course
  • Risk Burn Down Graphs / Charts
    • to show the risk exposure of the project
    • created by plotting the sum of the agreed risk exposure values (impact x probability) against iterations
    • to be updated regularly (per iteration) to reflect the change in risk exposure
    • general recommendation: top 10 risks are included
    • the risk burn down chart should have the total risks heading down while the project progresses
  • Risk-based Burn Up Chart
    • tracks the targeted and actual product delivery progress
    • includes estimates of how likely the team is to achieve targeted value adjusted for risk by showing the optimistic, most likely and the worst-case scenario
  • Risk-based Spike
    • Spike: a rapid time-boxed experiment (by the developers) to learn just enough about the “unknown” of a user story for estimation / establishing realistic expectations / as a proof of concept
    • the “unknown” can be: new technologies, new techniques
    • can be a “proof of concept”
    • spikes are carried out between sprints and before major epics / user stories
    • products of a spike are usually intended to be thrown away
    • types [for XP]:
      • architectural spike: associated with an unknown area of the system, technology or application domain
      • non-architectural spike: others
    • Risk based spike: a spike to allow the team to eliminate or minimize some major risks
      • if the spike fails for every approach available, the project reaches a condition known as “fast failure”, the cost of failure is much less than failing later

Summary: Risk Management

This PMI-ACP® Exam Study notes touches upon one of the many tools and techniques of the PMI-ACP® exam syllabus – Agile Risk Management. Risk Management includes Risk Adjusted Backlog, Risk Burn Down Graphs and Risk-based Spike.

 

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 *