Posted by SCRUMstudy® on February 16, 2023
Categories: Agile SBOK® Guide Scrum Scrum Master Sprint Backlog
Managing risk must be done proactively, and it is an iterative process that should begin at project inception and continue throughout the life of the project. The process of risk management should follow some standardized steps to ensure that risks are identified, evaluated, and a proper course of action is determined and acted upon accordingly.
In a Scrum environment, risks are generally minimized, largely due to the work being done in Sprints whereby a continuous series of Deliverables is produced in very short cycles, Deliverables are compared to expectations, and the Product Owner is actively engaged in the project. However, even in the simplest of projects, things can go wrong, so it is important to have a strategy to identify and address risks.
While some risks are specifically related to individual projects, others may originate in programs or portfolios and will generally be managed there itself. However, risks related to a portfolio or program will also impact projects that are part of the respective portfolio or program. During risk assessment in portfolios and programs, if it is determined that a risk may affect an individual project, relevant information about the risk must be communicated to the Product Owner and Scrum Team. Depending on the severity or priority, when the program or portfolio team communicates a risk that will impact an individual project, the Scrum Team may have to stop and re-plan the current Sprint to address the risk. For less urgent risks, the team can continue the current Sprint and address the risk in a subsequent Sprint.
In Portfolio
2. The Portfolio Product Owner will also need to communicate the risks to the relevant business stakeholders, the program teams, and the project teams. In some cases, the portfolio team may have to assume the ownership of specific risks.
In Program
2. The Program Product Owner will also need to communicate the risks to relevant business stakeholders and the project teams. In some cases, the program team would have to assume ownership of specific risks.