Usually in an agile process such as scrum we don't do an initial analysis as in waterfall model. How to identify project risk in agile process.
I disagree with the statement,that in SCRUM risk analysis is not done upfront
What about --
Risk analysis when a story is groomed & estimated during SPRINT plannnig --->
Considering & factoring in risks ( and considering mitigation - new stories ?? , "story is too big and risk -- break it down " , "no test to catch regression -- can not committ to this story unless regression tests are written " etc etc ) when story is groomed ?
Considering & factoring in risks when story points are being estimated ?
I do not think one is implementing SCRUM properly if formal risk analysis is not part of the SPRINT planning process ! I would be very nervous as a PM,if risks are not analysed,discussed and mitigations proposed before committing a story to the board
No matter what development methodology you are using there are a number of risks that can be known up front. These need to be identified and mitigated. During the project it is likely additional risks will be identified.
Many of the risks are fairly standard, and have known solutions. Identifying them and putting mitigating practices in places is important. Here a list of some of the risks you may want to consider.
- Web design has a number of risks including SQL injection, insecure logins, cross-site scripting and others. See SANS: CWD/SANS TOP 25 Most Dangerous Software Errors for some examples.
- Cyber security risks, see SANS: The Top Cyber Security Risks and SANS: Top 20 Internet Security Problems for some details.
- Failure to adequately secure payment data. Compliance with Payment Card Industry Data Security Standard is a starting point.
There are additional project specific risk which need to be dealt with on a per project basis. These include:
- Technical risk in implementing new functionality.
- Staffing/skills risk for the team. The team may not have all the skills it needs. You may have a limited number of team members with a critical skill. Agile may make it easy to develop and/or transfer skills.
- The risk of missed or unnecessary requirements. Agile may help mitigate this risk.
- Scope creap risk (additional out of scope requirements added during the project). Agile may help accommodate/deal with the problem.
The problem isn't that risk management is not done upfront in Agile software development processes. The problem is that risk management is not done explicitly, that is, risk management is implied in Agile processes so teams don't have the same notion of risk management as traditional project management expects. This is not to say that explicit risk management and agile cannot work together.
The SEI's Continuous Risk Management paradigm fits very well with agile processes. The best way I know to combine CRM with Agile is to perform a "mini" Software Risk Evaluation workshop using the SEI's risk taxonomy-based questionnaire as a guide. Mini-SRE's take anywhere from a few hours to a day to complete and not only teach a team what they need to know to identify and manage risks but also creates the initial risk backlog necessary to move forward with other parts of Agile processes. Such a workshop should happen during Sprint 0 and act as a guide for helping the customer decide which things to work on first, and other non-development things the team should be working on.