Problem Detection and Resolution - Part 2 Tutorial

Metric refers to a standard for measuring or evaluating something. Measure is a quantity. For example, there are twenty five open defect reports on the application as of today. Measure can be a proportion. For example, there are ten percent fewer open defect reports this week than the last week. Further, measure can also be a qualitative comparison. For example, the new version of the software is easier to use than the old version.

1 Problem Detection and Resolution

Hello and welcome to Domain VI—Problem Detection and Resolution of the PMI-ACP Certification course offered by Simplilearn. This is the second part of this domain.

2 Objectives

After completing this lesson, you will be able to: • Explain metrics and its types • Identify the steps involved in Agile risk management • Describe the steps in Risk Management Lifecycle • Explain how progressive risk reduction is achieved • Define Spike in Agile • Identify Agile coach failure modes

4 Benefits of Metrics

Metrics are important for the success of a project. When there is a measure to track the process, it becomes easier to understand if the process is effective. Metrics are beneficial to a project as they help in retrospectives, provide continuous feedback, and help in maintaining a high-quality code base and timely refactoring of code or code complexity. Metrics also support frequent releases and identify issues at the early project phase.

5 Types of Metrics

Some of the most commonly used metrics in projects are Business Metrics, Process Metrics, and Project Testing Metrics. This is only an illustrative list. The metric selection is based on its importance and value addition to the project. Click each heading to know more. Business Metrics include Running Tested Features or RTF, Earned Business Value or EBV, Net Present Value or NPV, Return on Investment or ROI, and Internal Rate of Return or IRR. Process Metrics include impediments cleared per iteration, impediments and user stories carried over to the next iteration, user stories done per iteration, defects that are carried forward to the next iteration, team member loading, velocity, and backlog size. Project Testing Metrics include acceptance tests per story, defects count per story, escaped defects per cycle, time to run tests, tests run per frequency, and time to fix tests.

6 Baseline Metrics

Baseline metrics are the calculations that result in the baseline data for a project. Some of the baseline measures used for comparison are as follows: • Number of planned sprints in a given release • Length of each sprint in calendar days • Number of story points planned for the release • Planned budget for the release, and • Start date of the project

7 Actual Metrics or Actuals

Actual metrics or actuals are the observations that need to be compared against the baseline. Some of the measures that can be used are as follows: Expected percent complete: This is calculated by dividing the number of sprints completed by the total number of sprints planned. Actual cost to date: This is the total cost incurred by the project to the latest iteration. Cumulative story points completed: This measures the total amount of work completed for the release within that sprint boundary, and Net story points added: This is the total of new story points added minus any story points removed.

8 Best Practices

Some of the best practices for using metrics in projects are: • Measure the outcomes, not the outputs • Measure the results, not the activity, as activity is meaningless without results • Measure the work completed, not the time spent per task • Follow the trends and not the absolute numbers

9 Burn Charts

Burn charts are part of information radiator family and help the team showcase and track the project progress. These charts are used in Agile projects to showcase some of the project metrics, such as total scope, amount of work completed, and amount of work remaining. The burndown chart shows how much work is to be completed in an iteration or release. The burnup chart shows how much work has been completed by the team in an iteration or release. The combined burn chart shows both the work completed as well as the work remaining in an iteration or release.

10 Variance Analysis

Variance Analysis is a quantitative analysis of the deviation between the ‘Planned’ and ‘Actuals.’ Variance is normal as long as it is within the permissible limits. If it is beyond the set limits, necessary actions must be taken immediately. Variance can be of two types, Common Cause Variations and Special Cause Variations. Click each heading to know more. Common Cause Variations are characterised by minor deviations from the expected results. They are the factors inherent in the system or process. Such variations have minimal impact on the outcome, hence no control actions are required. For example, if the velocity trend of a team is 56, 60, 63, 59, and 61, it can be stated that the team is delivering consistently. These small variations are within acceptable limits, given the dynamic nature of the project. Therefore, control actions are not required. Special Cause Variations are characterised by major deviations from the expected results and the underlying reasons are special or new factors. Unless proactively managed, these factors will make the process completely out of control. Hence, timely control actions should be taken to avoid its recurrence. For example, if the velocity trend of the team is 56, 30, 60, 35, and 25, notice that while the team is able to deliver 56 story points in one sprint, they have delivered only half the velocity in the next sprint. Such large variations should be proactively monitored as they can make the project delivery unpredictable. Hence, necessary control actions should be taken.

11 Trend Analysis

‘Trend Analysis’ refers to analyzing the measurements taken over time to gain a better understanding of the performance of a metric. It helps management to predict the future outcome of the project. Trend analysis also enables the team to predict potential problems, which results in taking preventive actions. Trend analysis can be more effective when two or more metrics are combined. Tracking their trend over time helps to understand the influence of one metric over the other. Such observations can be used to improve the project processes and practices. For example, if there are 25 risks identified at the beginning of the project, it conveys little meaning. However, if the number of risks reduces over time, it means that the risk management in the project is highly effective. On the contrary, the increasing risk trend signifies that the risk management strategy needs to be refined for the project.

12 Variance and Trend Analysis

The graph given on the screen shows the variance in the estimates and actuals of a typical project. Observe the trend over a period of five iterations. If the velocity of Iteration 1 is 20 story points and the plan was to complete 30 story points, then the variance at the end of Iteration 1 is 10 story points. This is depicted by the gap that exists between the two lines representing actuals and estimates. By tracking this metric on each sprint, you can observe how well the project is trending with respect to the plan and accordingly make some decisions.

13 Risk Management in Agile

In Agile projects, risks are managed by associating user stories to themes and ensuring that they are prioritized early in the project iterations. The risk management process is repeated in every iteration. The goal of each iteration should be to progressively ‘de-risk’ the project. As part of the iteration retrospective: • The remaining risks can be reviewed and the probabilities and impacts can be validated. • The team can be asked to identify new risks, and • The remaining features that continue to carry risk would be identified for selection in the next iteration. The illustration given on the screen shows how Agile projects inherently include an element of risk management. The process of risk management is carried out for each iteration in the project. The review at the end of iteration determines the actual performance against the plan. Also, the learnings from one iteration are incorporated in the next iteration. This process of feedback and learning builds the team’s confidence as they progress in the project. The key to this process is that the team must be encouraged to identify the risks and analyze them at every available opportunity.

14 Risk Management Lifecycle

There are four steps in risk management lifecycle such as risk identification, risk assessment, risk response, and risk review. First, the risks are identified by the team during daily scrum retrospection, requirement workshop, sprint planning, and sprint reviews. The team must be encouraged to highlight the risks whenever they become aware of it. After identifying the risks, the team must proceed to assess the risk for impact, probability, frequency, and urgency. At this stage, the team should have a good understanding of the risk level in the project and take necessary actions. The team should also be able to capture the likelihood and impact of risks. After assessing the risks, the team must identify an appropriate response. The response can be the decision to avoid, mitigate, transfer, or accept the risk as is. Finally, the team must perform risk review, where the team constantly reviews and updates the risk. Retrospective is a key forum in this stage.

15 Step 1-Risk Identification

The first step is risk identification. The team is responsible for identifying the risks and recording them in a risk register or spreadsheet. Risk identification is done using information gathering techniques, such as checklists, document reviews, and assumption analysis. Project manager must encourage the team to identify and reduce risks. This will help project become more predictable, which reduces the chances of unpleasant surprises during the execution.

16 Risk Identification Opportunities

Risk identification in a project can happen at the following stages: During Requirement Gathering, team and the product manager discuss new ideas to consider and adjust requirements in a way that maximizes value and minimizes risk. During estimation using techniques such as Planning Poker, the team estimates the relative size of each user story. The team must pay attention to the composition of larger stories that have greater uncertainty associated with them. Rejecting user stories that are over a certain size helps reduce risk. During Iteration or Sprint Planning, the team identifies, assesses, and responds to risk. Team works with the Product Manager to maximize output, thereby reducing the risk of failure. During the Scrum Meeting or daily stand-up meeting, the team identifies risks and issues. The team members add the risks to the risk board and document the agreed response plan. They should identify the blocking issues that may have an impact in their ability to work. The team must also take appropriate actions. During the Iteration or Sprint Review meeting, the team discusses risks. The team members should highlight successful mitigation or evasion activities and share them with the stakeholders. Further, during the Retrospective meeting, the team discusses risks handled successfully, the chances of reoccurrence of risk, and what will be done differently for risk mitigation in the subsequent iteration or sprint.

17 Step 2-Risk Assessment

The second step in risk management lifecycle is risk assessment. The risks identified in Step 1 need to be assessed based on the probability of failure, impact, or loss generated by the risk. This information can be used to prioritize risks and identify the risk response strategy. A broad categorization is business risk, technological risk, and logistical risk. To ensure that a wide range of risks have been identified, the acronym P E S T L E can be used. P stands for Political risks arising from political influences that govern a project; E stands for Environmental risks; S stands for Societal risks; T stands for Technological risks; L stands for Legal risks, and E stands for Economic risks.

18 Risk Assessment-Risk Census

A risk census is a simple framework for analyzing the risk exposure of a project. Risk census describes each risk and provides an estimate of how likely the risk is to occur. It also indicates the impact to the schedule if the risk occurs, and identifies the expected exposure to the risk. The total exposure can be used to determine how much slack or buffer is required in the project. The risk exposure is calculated by multiplying the probability, which is expressed as a fraction, and the impact.

19 Step 2-Risk Assessment

Risk Board is an information radiator used to make the risks of a project transparent to the team and the stakeholders. A risk board indicates the identified risks, probabilities, impact, and risk response, if applicable. Stories with high impact and probability will have higher risk. The team should closely monitor these stories, discuss ways to minimize or mitigate them, and use a spike to reduce uncertainty in the story. Risk board should be reviewed regularly as part of the daily Scrum and or as part of the end-of-sprint or iteration retrospective. Click the ‘Example’ button to view an example of a risk board. An example of a risk board with identified risks, probability, impact, and risk exposure is given in the table. It is recommended to spend some time and go through the contents for a better understanding of the concept.

20 Step 3-Risk Response Strategies

Every risk identified should have a response strategy. There are four types of response strategies, avoid, mitigate, transfer, and accept. Avoid Strategy: The entire project or part of a project is cancelled to remove the threat of risk realization. Note that it is sometimes possible to completely avoid a risk. For example, if a particular story is risky, the ‘avoid strategy’ can be used to remove the story from the backlog. Mitigate Strategy: This strategy reduces the impact or probability of the risks or sometimes both, if the event occurs. For example, if a team is aware of their velocity, they can confidently predict the amount of work that can be done in the iteration. This mitigates the risk of over-commitment or under-commitment during the iteration planning. Transfer Strategy: A commonly employed transfer strategy is ‘outsourcing’, where the work is assigned to a third party. Note that residual risks are not eliminated completely even after transferring. These must be handled using different strategies. Accept Strategy: In this strategy, the team decides not to take any action against risk. However, the team agrees to handle the lower impact risks, when they arise.

21 Step 4-Risk Review

In the risk review phase, the team meets to review the outstanding risks, reassess the risk exposure, and gauge the effectiveness of risk responses. The outcome can be used to refine the overall risk management strategy. The key focus during risk reviews are as follows: • The active risks are reviewed to ensure that responses are delivered in a timely and efficient manner, through the ‘daily scrum’. Actions and decision points are added to the risk board and reviewed every day. • The team needs to provide feedback on the risk management process to ensure that it is optimized as a part of the project retrospective. • Review of the risk impact and risk realizations on project and company objectives is conducted as part of the sprint or iteration planning activities. Note that the aim of risk reviews is to make the risks visible, monitor them regularly, prioritize the risk issues to elevate accountability, encourage action, and track ownership and resolution status.

22 Risk Log

The risks identified through the risk management lifecycle are captured and tracked in the risk log. Some of the key aspects of risk logs are as follows: • Risk score is computed for each of the identified risk using the formula: Probability of failure multiplied by Impact. Higher risk scores imply higher risks. • Risks are prioritized according to the risk score, and the owners responsible for resolving the risk are captured in the risk log. Risk logs need to be constantly monitored. If required, high impact risks must be escalated to appropriate stakeholder to get their attention, in turn foster quicker response. • Risk log is one of the key information radiators that helps in ensuring transparency, accountability, encouraging actions, and resolution status. Click the ‘Sample’ button given on the screen to view a risk log sample. A sample risk log is shown here. Some of the key information captured are: • Reference number, • Detailed description about the risk, • Date on which the risk was identified, • Likelihood of the risk occurrence, • Impact if the risk materializes, • Risk category, • Risk response or countermeasures, • Contingencies, and • Owner accountable for resolving the risk.

23 Risk Burndown Chart

The Risk Burndown chart is a simple graphical indicator of the risk trends in a project. Risk burndown charts are created by plotting the sum of the risk exposure or Expected Monetary Value or EMV on a project determined from the risk census against time or iterations. In this chart, the overall risk level on a project must reduce as time progresses and the team must drive uncertainty out of the project. There should be a linear drop in risk over the course of the project. Each iteration should de-risk the project by delivering a user story that mitigates or eliminates risk on the risk board. This chart gives a visual proof of de-risking. A sample risk burndown chart is given on the screen for reference.

24 Risk Profile Graphs

A risk profile graph is an elaborate version of the Risk Burndown chart. Each identified risk is closely tracked in this graph. It also showcases if the overall risk exposure of the project is increasing or decreasing over the course of a project. These graphs are ‘stacked area graphs’ of risk severity. The risk severity scores for each risk are plotted one over the other to give a cumulative severity profile of the project. The area under the top line shows which of the risks is contributing most to the riskiness of the project. These graphs also inform stakeholders if the risks are moving in the right direction, that is downwards, or if issues and concerns are escalating, that is upwards. A sample risk profile graph is illustrated on the screen for your reference.

25 Progressive Risk Reduction

The steps to reduce the risk levels of a project are as follows: 1. Identify risks as early as possible. Awareness gives you the power and time to handle risks. 2. Perform continuous risk assessment. Over time, new risks may arise and some of the identified risks may become redundant. 3. Introduce features to handle risks. For example, if the project has more technical debt and the quality is unstable, one must plan for stabilization stories to shape the level of defects and instability. 4. Collect early and continuous feedback from the team. Constantly prioritizing risks and including their responses into the product backlog results in creating a Risk Adjusted Product Backlog.

26 Spike

Spike is an innovation developed in Extreme Programming that is used to remove uncertainty. Spike is a timeboxed period designated to reduce uncertainty by learning about a feature, technology, or process. This helps to better estimate and develop an upcoming feature or fix defect. A spike helps in reducing project risks by doing an early architectural envisioning. It should require minimal time and effort; not more than two days. Further, a spike should be made visible by creating a story for it in the product backlog and must be used sparingly, as they do not create story points. The given image represents a product backlog with spike stories.

27 Agile Failure Modes

In Scrum, the concept of ‘ScrumBut’ refers to the proverb “Agile practices don’t fail –rather the variations on Agile adoption fail.” Failure of Agile projects is most often due to the following reasons: • Culture does not support the change. • Lack of reward plan and existence of a static and prescriptive standard of work. • Lack of retrospectives. • Actions that are outcome of the sprint or release retrospection gets ignored or written off. • Lack of collaboration in planning • ScrumMaster who uses a command and control style to speed up project progress, but in reality slows things down.

28 Agile Coach Failure Modes

Lyssa Atkins has identified seven types of Agile Coach failure modes. They are The Spy, The Seagull, The Opinionator, The Admin, The Hub, The Butterfly, and The Expert. Click each tab to know more. The ‘Spy’ spends most of the time observing the team to pick up topics for the next retrospective. The coach acts as a spy. The ‘Seagull’ criticizes the teams, and does not give constructive ideas to address problems. The ‘Opinionator’ gets attached to their opinion and lose the objectivity needed to help the team have fruitful discussions. The coach is closed to inputs and sticks to their opinions at all costs. The 'Admin’ undermines the team ownership by becoming an unnecessary middle-man for meeting logistics, access requests, and other jobs. The coach assumes the role of an administrator, between processes, hence slowing things down. The ‘Hub’ acts as a single point of contact for communication between team members and for task-level coordination. The coach positions as the hub – the central point of all project events, instead of being a facilitator. The 'Butterfly’ spends just enough time to advice or pose a question, before leaving for another meeting or issue that needs attention. Like a butterfly, the coach moves from team-to-team only to advice, but not spending enough to make a real difference. The ‘Experts’ are so involved in the details of the team that they do not see the broader goals of the projects. They focus on the details of implementing stories.

29 Quiz

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

30 Summary

Let us summarize the topics covered in this lesson: • Metrics are important for evaluation of a project. Business Metrics, Process Metrics, and Project Testing Metrics are the three major categories of commonly used metrics. • A risk census is a simple framework for analyzing the risk exposure of a project. • Risk Board is an information radiator used to make the risks of a project transparent to the team and the stakeholders. • Avoid, Mitigate, Transfer, and Accept are the four risk response strategies. • Risk Burndown Chart is a simple graphical indicator of the risk trends in the project. • Risk Profile Graphs inform stakeholders if the project risks are increasing or decreasing. • Spike is a timeboxed period designated to reduce uncertainty by learning about a feature, technology, or process. • In Scrum, the term ‘ScrumBut’ refers to the proverb, “Agile practices don't fail—rather the variations on Agile adoption fail.”

31 Conclusion

This concludes Domain VI—Problem Detection and Resolution. The next domain is ‘Continuous Improvement.’

1 Problem Detection and Resolution

Hello and welcome to Domain VI—Problem Detection and Resolution of the PMI-ACP Certification course offered by Simplilearn. This is the second part of this domain.

2 Objectives

After completing this lesson, you will be able to: • Explain metrics and its types • Identify the steps involved in Agile risk management • Describe the steps in Risk Management Lifecycle • Explain how progressive risk reduction is achieved • Define Spike in Agile • Identify Agile coach failure modes

4 Benefits of Metrics

Metrics are important for the success of a project. When there is a measure to track the process, it becomes easier to understand if the process is effective. Metrics are beneficial to a project as they help in retrospectives, provide continuous feedback, and help in maintaining a high-quality code base and timely refactoring of code or code complexity. Metrics also support frequent releases and identify issues at the early project phase.

5 Types of Metrics

Some of the most commonly used metrics in projects are Business Metrics, Process Metrics, and Project Testing Metrics. This is only an illustrative list. The metric selection is based on its importance and value addition to the project. Click each heading to know more. Business Metrics include Running Tested Features or RTF, Earned Business Value or EBV, Net Present Value or NPV, Return on Investment or ROI, and Internal Rate of Return or IRR. Process Metrics include impediments cleared per iteration, impediments and user stories carried over to the next iteration, user stories done per iteration, defects that are carried forward to the next iteration, team member loading, velocity, and backlog size. Project Testing Metrics include acceptance tests per story, defects count per story, escaped defects per cycle, time to run tests, tests run per frequency, and time to fix tests.

6 Baseline Metrics

Baseline metrics are the calculations that result in the baseline data for a project. Some of the baseline measures used for comparison are as follows: • Number of planned sprints in a given release • Length of each sprint in calendar days • Number of story points planned for the release • Planned budget for the release, and • Start date of the project

7 Actual Metrics or Actuals

Actual metrics or actuals are the observations that need to be compared against the baseline. Some of the measures that can be used are as follows: Expected percent complete: This is calculated by dividing the number of sprints completed by the total number of sprints planned. Actual cost to date: This is the total cost incurred by the project to the latest iteration. Cumulative story points completed: This measures the total amount of work completed for the release within that sprint boundary, and Net story points added: This is the total of new story points added minus any story points removed.

8 Best Practices

Some of the best practices for using metrics in projects are: • Measure the outcomes, not the outputs • Measure the results, not the activity, as activity is meaningless without results • Measure the work completed, not the time spent per task • Follow the trends and not the absolute numbers

9 Burn Charts

Burn charts are part of information radiator family and help the team showcase and track the project progress. These charts are used in Agile projects to showcase some of the project metrics, such as total scope, amount of work completed, and amount of work remaining. The burndown chart shows how much work is to be completed in an iteration or release. The burnup chart shows how much work has been completed by the team in an iteration or release. The combined burn chart shows both the work completed as well as the work remaining in an iteration or release.

10 Variance Analysis

Variance Analysis is a quantitative analysis of the deviation between the ‘Planned’ and ‘Actuals.’ Variance is normal as long as it is within the permissible limits. If it is beyond the set limits, necessary actions must be taken immediately. Variance can be of two types, Common Cause Variations and Special Cause Variations. Click each heading to know more. Common Cause Variations are characterised by minor deviations from the expected results. They are the factors inherent in the system or process. Such variations have minimal impact on the outcome, hence no control actions are required. For example, if the velocity trend of a team is 56, 60, 63, 59, and 61, it can be stated that the team is delivering consistently. These small variations are within acceptable limits, given the dynamic nature of the project. Therefore, control actions are not required. Special Cause Variations are characterised by major deviations from the expected results and the underlying reasons are special or new factors. Unless proactively managed, these factors will make the process completely out of control. Hence, timely control actions should be taken to avoid its recurrence. For example, if the velocity trend of the team is 56, 30, 60, 35, and 25, notice that while the team is able to deliver 56 story points in one sprint, they have delivered only half the velocity in the next sprint. Such large variations should be proactively monitored as they can make the project delivery unpredictable. Hence, necessary control actions should be taken.

11 Trend Analysis

‘Trend Analysis’ refers to analyzing the measurements taken over time to gain a better understanding of the performance of a metric. It helps management to predict the future outcome of the project. Trend analysis also enables the team to predict potential problems, which results in taking preventive actions. Trend analysis can be more effective when two or more metrics are combined. Tracking their trend over time helps to understand the influence of one metric over the other. Such observations can be used to improve the project processes and practices. For example, if there are 25 risks identified at the beginning of the project, it conveys little meaning. However, if the number of risks reduces over time, it means that the risk management in the project is highly effective. On the contrary, the increasing risk trend signifies that the risk management strategy needs to be refined for the project.

12 Variance and Trend Analysis

The graph given on the screen shows the variance in the estimates and actuals of a typical project. Observe the trend over a period of five iterations. If the velocity of Iteration 1 is 20 story points and the plan was to complete 30 story points, then the variance at the end of Iteration 1 is 10 story points. This is depicted by the gap that exists between the two lines representing actuals and estimates. By tracking this metric on each sprint, you can observe how well the project is trending with respect to the plan and accordingly make some decisions.

13 Risk Management in Agile

In Agile projects, risks are managed by associating user stories to themes and ensuring that they are prioritized early in the project iterations. The risk management process is repeated in every iteration. The goal of each iteration should be to progressively ‘de-risk’ the project. As part of the iteration retrospective: • The remaining risks can be reviewed and the probabilities and impacts can be validated. • The team can be asked to identify new risks, and • The remaining features that continue to carry risk would be identified for selection in the next iteration. The illustration given on the screen shows how Agile projects inherently include an element of risk management. The process of risk management is carried out for each iteration in the project. The review at the end of iteration determines the actual performance against the plan. Also, the learnings from one iteration are incorporated in the next iteration. This process of feedback and learning builds the team’s confidence as they progress in the project. The key to this process is that the team must be encouraged to identify the risks and analyze them at every available opportunity.

14 Risk Management Lifecycle

There are four steps in risk management lifecycle such as risk identification, risk assessment, risk response, and risk review. First, the risks are identified by the team during daily scrum retrospection, requirement workshop, sprint planning, and sprint reviews. The team must be encouraged to highlight the risks whenever they become aware of it. After identifying the risks, the team must proceed to assess the risk for impact, probability, frequency, and urgency. At this stage, the team should have a good understanding of the risk level in the project and take necessary actions. The team should also be able to capture the likelihood and impact of risks. After assessing the risks, the team must identify an appropriate response. The response can be the decision to avoid, mitigate, transfer, or accept the risk as is. Finally, the team must perform risk review, where the team constantly reviews and updates the risk. Retrospective is a key forum in this stage.

15 Step 1-Risk Identification

The first step is risk identification. The team is responsible for identifying the risks and recording them in a risk register or spreadsheet. Risk identification is done using information gathering techniques, such as checklists, document reviews, and assumption analysis. Project manager must encourage the team to identify and reduce risks. This will help project become more predictable, which reduces the chances of unpleasant surprises during the execution.

16 Risk Identification Opportunities

Risk identification in a project can happen at the following stages: During Requirement Gathering, team and the product manager discuss new ideas to consider and adjust requirements in a way that maximizes value and minimizes risk. During estimation using techniques such as Planning Poker, the team estimates the relative size of each user story. The team must pay attention to the composition of larger stories that have greater uncertainty associated with them. Rejecting user stories that are over a certain size helps reduce risk. During Iteration or Sprint Planning, the team identifies, assesses, and responds to risk. Team works with the Product Manager to maximize output, thereby reducing the risk of failure. During the Scrum Meeting or daily stand-up meeting, the team identifies risks and issues. The team members add the risks to the risk board and document the agreed response plan. They should identify the blocking issues that may have an impact in their ability to work. The team must also take appropriate actions. During the Iteration or Sprint Review meeting, the team discusses risks. The team members should highlight successful mitigation or evasion activities and share them with the stakeholders. Further, during the Retrospective meeting, the team discusses risks handled successfully, the chances of reoccurrence of risk, and what will be done differently for risk mitigation in the subsequent iteration or sprint.

17 Step 2-Risk Assessment

The second step in risk management lifecycle is risk assessment. The risks identified in Step 1 need to be assessed based on the probability of failure, impact, or loss generated by the risk. This information can be used to prioritize risks and identify the risk response strategy. A broad categorization is business risk, technological risk, and logistical risk. To ensure that a wide range of risks have been identified, the acronym P E S T L E can be used. P stands for Political risks arising from political influences that govern a project; E stands for Environmental risks; S stands for Societal risks; T stands for Technological risks; L stands for Legal risks, and E stands for Economic risks.

18 Risk Assessment-Risk Census

A risk census is a simple framework for analyzing the risk exposure of a project. Risk census describes each risk and provides an estimate of how likely the risk is to occur. It also indicates the impact to the schedule if the risk occurs, and identifies the expected exposure to the risk. The total exposure can be used to determine how much slack or buffer is required in the project. The risk exposure is calculated by multiplying the probability, which is expressed as a fraction, and the impact.

19 Step 2-Risk Assessment

Risk Board is an information radiator used to make the risks of a project transparent to the team and the stakeholders. A risk board indicates the identified risks, probabilities, impact, and risk response, if applicable. Stories with high impact and probability will have higher risk. The team should closely monitor these stories, discuss ways to minimize or mitigate them, and use a spike to reduce uncertainty in the story. Risk board should be reviewed regularly as part of the daily Scrum and or as part of the end-of-sprint or iteration retrospective. Click the ‘Example’ button to view an example of a risk board. An example of a risk board with identified risks, probability, impact, and risk exposure is given in the table. It is recommended to spend some time and go through the contents for a better understanding of the concept.

20 Step 3-Risk Response Strategies

Every risk identified should have a response strategy. There are four types of response strategies, avoid, mitigate, transfer, and accept. Avoid Strategy: The entire project or part of a project is cancelled to remove the threat of risk realization. Note that it is sometimes possible to completely avoid a risk. For example, if a particular story is risky, the ‘avoid strategy’ can be used to remove the story from the backlog. Mitigate Strategy: This strategy reduces the impact or probability of the risks or sometimes both, if the event occurs. For example, if a team is aware of their velocity, they can confidently predict the amount of work that can be done in the iteration. This mitigates the risk of over-commitment or under-commitment during the iteration planning. Transfer Strategy: A commonly employed transfer strategy is ‘outsourcing’, where the work is assigned to a third party. Note that residual risks are not eliminated completely even after transferring. These must be handled using different strategies. Accept Strategy: In this strategy, the team decides not to take any action against risk. However, the team agrees to handle the lower impact risks, when they arise.

21 Step 4-Risk Review

In the risk review phase, the team meets to review the outstanding risks, reassess the risk exposure, and gauge the effectiveness of risk responses. The outcome can be used to refine the overall risk management strategy. The key focus during risk reviews are as follows: • The active risks are reviewed to ensure that responses are delivered in a timely and efficient manner, through the ‘daily scrum’. Actions and decision points are added to the risk board and reviewed every day. • The team needs to provide feedback on the risk management process to ensure that it is optimized as a part of the project retrospective. • Review of the risk impact and risk realizations on project and company objectives is conducted as part of the sprint or iteration planning activities. Note that the aim of risk reviews is to make the risks visible, monitor them regularly, prioritize the risk issues to elevate accountability, encourage action, and track ownership and resolution status.

22 Risk Log

The risks identified through the risk management lifecycle are captured and tracked in the risk log. Some of the key aspects of risk logs are as follows: • Risk score is computed for each of the identified risk using the formula: Probability of failure multiplied by Impact. Higher risk scores imply higher risks. • Risks are prioritized according to the risk score, and the owners responsible for resolving the risk are captured in the risk log. Risk logs need to be constantly monitored. If required, high impact risks must be escalated to appropriate stakeholder to get their attention, in turn foster quicker response. • Risk log is one of the key information radiators that helps in ensuring transparency, accountability, encouraging actions, and resolution status. Click the ‘Sample’ button given on the screen to view a risk log sample. A sample risk log is shown here. Some of the key information captured are: • Reference number, • Detailed description about the risk, • Date on which the risk was identified, • Likelihood of the risk occurrence, • Impact if the risk materializes, • Risk category, • Risk response or countermeasures, • Contingencies, and • Owner accountable for resolving the risk.

23 Risk Burndown Chart

The Risk Burndown chart is a simple graphical indicator of the risk trends in a project. Risk burndown charts are created by plotting the sum of the risk exposure or Expected Monetary Value or EMV on a project determined from the risk census against time or iterations. In this chart, the overall risk level on a project must reduce as time progresses and the team must drive uncertainty out of the project. There should be a linear drop in risk over the course of the project. Each iteration should de-risk the project by delivering a user story that mitigates or eliminates risk on the risk board. This chart gives a visual proof of de-risking. A sample risk burndown chart is given on the screen for reference.

24 Risk Profile Graphs

A risk profile graph is an elaborate version of the Risk Burndown chart. Each identified risk is closely tracked in this graph. It also showcases if the overall risk exposure of the project is increasing or decreasing over the course of a project. These graphs are ‘stacked area graphs’ of risk severity. The risk severity scores for each risk are plotted one over the other to give a cumulative severity profile of the project. The area under the top line shows which of the risks is contributing most to the riskiness of the project. These graphs also inform stakeholders if the risks are moving in the right direction, that is downwards, or if issues and concerns are escalating, that is upwards. A sample risk profile graph is illustrated on the screen for your reference.

25 Progressive Risk Reduction

The steps to reduce the risk levels of a project are as follows: 1. Identify risks as early as possible. Awareness gives you the power and time to handle risks. 2. Perform continuous risk assessment. Over time, new risks may arise and some of the identified risks may become redundant. 3. Introduce features to handle risks. For example, if the project has more technical debt and the quality is unstable, one must plan for stabilization stories to shape the level of defects and instability. 4. Collect early and continuous feedback from the team. Constantly prioritizing risks and including their responses into the product backlog results in creating a Risk Adjusted Product Backlog.

26 Spike

Spike is an innovation developed in Extreme Programming that is used to remove uncertainty. Spike is a timeboxed period designated to reduce uncertainty by learning about a feature, technology, or process. This helps to better estimate and develop an upcoming feature or fix defect. A spike helps in reducing project risks by doing an early architectural envisioning. It should require minimal time and effort; not more than two days. Further, a spike should be made visible by creating a story for it in the product backlog and must be used sparingly, as they do not create story points. The given image represents a product backlog with spike stories.

27 Agile Failure Modes

In Scrum, the concept of ‘ScrumBut’ refers to the proverb “Agile practices don’t fail –rather the variations on Agile adoption fail.” Failure of Agile projects is most often due to the following reasons: • Culture does not support the change. • Lack of reward plan and existence of a static and prescriptive standard of work. • Lack of retrospectives. • Actions that are outcome of the sprint or release retrospection gets ignored or written off. • Lack of collaboration in planning • ScrumMaster who uses a command and control style to speed up project progress, but in reality slows things down.

28 Agile Coach Failure Modes

Lyssa Atkins has identified seven types of Agile Coach failure modes. They are The Spy, The Seagull, The Opinionator, The Admin, The Hub, The Butterfly, and The Expert. Click each tab to know more. The ‘Spy’ spends most of the time observing the team to pick up topics for the next retrospective. The coach acts as a spy. The ‘Seagull’ criticizes the teams, and does not give constructive ideas to address problems. The ‘Opinionator’ gets attached to their opinion and lose the objectivity needed to help the team have fruitful discussions. The coach is closed to inputs and sticks to their opinions at all costs. The 'Admin’ undermines the team ownership by becoming an unnecessary middle-man for meeting logistics, access requests, and other jobs. The coach assumes the role of an administrator, between processes, hence slowing things down. The ‘Hub’ acts as a single point of contact for communication between team members and for task-level coordination. The coach positions as the hub – the central point of all project events, instead of being a facilitator. The 'Butterfly’ spends just enough time to advice or pose a question, before leaving for another meeting or issue that needs attention. Like a butterfly, the coach moves from team-to-team only to advice, but not spending enough to make a real difference. The ‘Experts’ are so involved in the details of the team that they do not see the broader goals of the projects. They focus on the details of implementing stories.

29 Quiz

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

30 Summary

Let us summarize the topics covered in this lesson: • Metrics are important for evaluation of a project. Business Metrics, Process Metrics, and Project Testing Metrics are the three major categories of commonly used metrics. • A risk census is a simple framework for analyzing the risk exposure of a project. • Risk Board is an information radiator used to make the risks of a project transparent to the team and the stakeholders. • Avoid, Mitigate, Transfer, and Accept are the four risk response strategies. • Risk Burndown Chart is a simple graphical indicator of the risk trends in the project. • Risk Profile Graphs inform stakeholders if the project risks are increasing or decreasing. • Spike is a timeboxed period designated to reduce uncertainty by learning about a feature, technology, or process. • In Scrum, the term ‘ScrumBut’ refers to the proverb, “Agile practices don't fail—rather the variations on Agile adoption fail.”

31 Conclusion

This concludes Domain VI—Problem Detection and Resolution. The next domain is ‘Continuous Improvement.’

Find our PMI-ACP® Certification Online Classroom training classes in top cities:


Name Date Place
PMI-ACP® Certification 15 Sep -6 Oct 2018, Weekend batch Your City View Details
  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy