Proactively identify or acknowledge risks
When a product backlog is initially created by the product owner, there will inevitably be items that scrum teams members and stakeholders identify as possible risks. Risk will also be identified during scrum team execution, sprint reviews and retrospectives that should be factored into the product backlog. All risks should be documented so that hits to the execution of the overall vision of the project, dependencies and potential missed items are assessed for management. Risk identification is a continuous process and scrum teams should be positively encouraged to identify all possible risks. No risk should be discounted and all risks should be documented. A risk cannot be prioritized if it is not first identified.
Risk Assessment
As part of the product backlog prioritization and continuous refinement process, risks that are identified should be assessed and re-assessed. Risks generally go into one of four categories:
- Risks that should be avoided
- Risks that will require implementation procedures to mitigate
- Risks that are transferred to other groups or individuals and
- Risks that are accepted.
Once a risk is assessed and placed into the proper category, impacts to the prioritization of features in the product backlog will become clearer. All risk assessment decisions should be documented by category, reason for the category, and updates as risks are either mitigated, transferred, accepted, or become issues that are critical to immediately address. Financial assessments of the impact of risks should also be taken into consideration. For example, if there are two risks that imprint higher priority items but, one risk could cost the company an additional $10,000 is development costs, then this risk moves higher in the priority list for resolution.
Risks can also be positive. These risks are similarly categorized into 4 areas:
- Risks that should be exploited.
- Risks that should be enhanced to increase the likelihood of its impact
- Risks that should be shared with a 3rd party or
- Risks that should be accepted but, not proactively sought out.
Positive risks are rarely identified in projects but, can have just as much of an effect. Too much of a good thing can turn into a threat. For example, if a company conducts a marketing campaign for your new project that turns potential sales into numbers that are not scalable, then your organization may not have adequately planned for scaling of production capabilities.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: