My history while using the Scrum framework is that the framework is all about taking risks early and often in the development of the application. With every sprint iteration, you are supposed to be building workable software for the business/stakeholder, so during every sprint, you will un-covering risks and exposing shortfalls in the project. I think the key is that you are performing this function from the first iteration, not trying to gather all the risks you can document upfront (waterfall) and wait till the end to see if the application is a viable entity. I think that there are a few techniques from the traditional project management rulebook that could work to your advantage while you implement the Scrum framework. Here are some risk identification processes that you can employ at the beginning of the project, and as discussed before every undertaking of a sprint should uncover risks. Combining together the two frameworks (agile/scrum-traditional pm) processes should give your project the one-two punch towards alleviating risks along the development path, BUT you will never alleviate risks all together it’s the nature of application development, but you can try to mitigate the risks. Risk Identification 1. Forming a risk team-Document the skill that each individual brings to the risk team, so when emergencies happen the right team skill sets are involved with the issues. 2. Brainstorming session-Document the participant perspectives on each risk item that you might uncover. 3. Prioritize brainstorming results-Prioritize each risk. 4. Identify Top Risks-Document that number, with a brief explanation of what these high-priority risks mean to your project. 5. Create your Response-Located and store together with the tools, instructions
Comments