Agile and risk management

Agile risk management

• Risk audit
• Risk contingency
• Risk mitigation
• Risk monitoring
• Risk-adjusted backlog
• Risk-based burnup chart
• Risk burn down graphs
• Risk–based spike

Risks

• The agile methodology generally deals with qualitative risks, not quantitative. [The Art of Agile Development. James Shore.]
  • Agile team follows Qualitative Risk analysis.
  • Quantitative risk analysis usually involves calculation of risk impact in monetary terms like Expected Monitory Value.
• Whole team is responsible for managing risk.
• This must have made you wonder then how come Project manager role.
  • It is important here to note that here we are not talking about agile and XP does recognize the role of Project Manager.
  • The overall risk management responsibility can be assigned to Project Manager.

Risks areas

• 5 core risks areas :
  • 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).
• [The Software Project Manager’s Bridge to Agility. Michele Sliger, Stacia Broderick.]

Risk audit

• A risk audit is typically performed in the iteration review after each iteration. [The Art of Agile Development. James Shore.]

Risk contingency

• A contingency activity is an activity ready for implementation to reduce risk impact should a risk occur. [The Art of Agile Development. James Shore.]
  • Team is keeping some contingency reserve to take care of unexpected tasks it falls in Contain.
  • In contain, we plan contingency reserve to take care of risk.

Risk mitigation

• Generally, risk mitigation is thought of as the reduction of the impact whether or not the risk occurs. [The Art of Agile Development. James Shore.]

Risk monitoring

• Risk is continuously monitored on an agile project through information radiators, daily stand-up meetings, iteration reviews, and iteration retrospectives. [The Art of Agile Development. James Shore.]
  • Through information radiators, daily stand-up meetings, iteration reviews, and iteration retrospectives.
  • In other words, risk is monitored and controlled throughout an agile project and in many different ways.
  • [The Art of Agile Development. James Shore.]

Risk-adjusted backlog

• A risk-adjusted backlog is a product backlog organized by taking into account risk.
  • Risk can be estimated as the product of severity/consequence and likelihood.
• Agile projects are both business-value & risk-driven !
  • We choose practical bundles of work based on assigned business priority and what risk items remain in the prioritized features
  • We calculate ROI for the project and let BI distribute this ROI on the several features (as each feature is value-added its % of importance in the global ROI is known)
  • Given this distribution we can calculate risk impact with the EMV (Expected Monetary Value) method
    • EMV = impact ($/€) x probability (%)
• User stories can also be positioned on a risk-to-value matrix to help prioritize them in the backlog.
  • The risk-to-value matrix is a chart with four quadrants.
    • Along the horizontal axis is value in ascending order.
    • Along the vertical axis is risk in ascending order.
    • A User Story that is high risk and high value is located in the top-right corner.
    • A User Story that is low risk and high value is located in the lower-right corner.
    • A User Story that is low risk and high value is located in the lower-right corner.
    • A User Story that is low risk and low value is located in the lower-left corner.
• Typically a team will prioritize high-value, low-risk user stories first, followed by high-value, high-risk User Stories, followed by low-value, low-risk user stories, followed by low-value, high-risk user stories. [The Art of Agile Development. James Shore.]
• New identified risk
  • Bring the newly identified risk to the team’s attention and to discuss its impact. [The Art of Agile Development. James Shore.] [Risk management]

Risk-based burn-up chart

• A risk-based burn-up chart tracks targeted and actual product delivery progress and also includes estimates of how likely the team is to achieve targeted value adjusted for risk.
  • Typically, risk is shown as three different levels: best-case; most likely; and worst-case.
  • For example, if you have a 10 iteration project and the team’s current velocity is 10 story points, you can portray the chance of completing 100 story points (most likely case), the chance of completing 80 story points (worst-case), and the chance of completing 120 story points (best-case).
  • In this way, the stakeholders get a feel for the range of risk.
  • [The Art of Agile Development. James Shore.]

Risk burn-down graphs

• A project manager may use a burndown chart and a team’s velocity to make sure the team is not under or over committing to an iteration.
  • A sustainable pace of development is an important facet of agile project planning and risk management. [The Art of Agile Development. James Shore.]
• A risk burndown chart is a risk management technique used to track project risk over time.
• It allows stakeholders to quickly review project risk management performance (e.g., increasing, decreasing, and by how much) over time.
  • Severity (a product of impact and probability) is charted along the vertical axis with time on the horizontal axis.
  • Impact typically takes a value from 0 to 5 in increasing order of risk and probability/likelihood typically takes a value from 0 to 5 in increasing order of probability.
  • In this example, the worst severity a risk could have is 25 (5 × 5 = 25) and the least harmful severity a risk could have is 0.
  • The agile team and customer/product owner identifies its risks and assigns severity values in a risk register and tracks those values over time. Ideally, risk severity will decrease over time.
  • [The Art of Agile Development. James Shore.]

Risk–based spike

• Risked-based Spike is a risk management technique and is often thought of as a task.
  • A risked-based Spike is a task used to gain knowledge in an area of uncertainty to reduce risk.
  • For example, Developers may need to understand how migrating from Windows 7 to Windows 8 may impact the look and feel of the interface.
  • Risked-based Spikes typically are included in iteration planning directly before a the task that holds the uncertainty.
  • [The Art of Agile Development. James Shore.]

More informations at PMI-ACP exam