1. Questions
1.1. Can risk factor lead to a reduction estimate?
1.2. Why people ignore the Risks?
2. Estimations
2.1. Types of estimations
2.1.1. By Time
2.1.1.1. Early estimations
2.1.1.2. Final estimations
2.1.2. By Approaches
2.1.2.1. Metrics-based approach
2.1.2.2. Experience-based approach
2.2. Purposes
2.2.1. Budget predictions to release the project (Project price)
2.2.2. Features assessment (not user stories)
2.2.3. Try to understand Customer "How to", not "How much"
2.2.4. Project planning
2.3. Extreme Ways
2.3.1. Extremely low risks
2.3.2. Extremely high risks
2.4. Prerequisites
2.4.1. "divide et impera"
2.4.2. Estimation tables
2.4.2.1. Light version
2.4.2.2. Common version
2.4.3. Experts
2.5. "To Do" steps
2.5.1. Estimation of estimation
2.5.2. Requirements analyzing
2.5.3. Draw estimations (simply, average, hard, etc)
2.5.4. Filling of estimation tables
2.6. "How To" estimate in hours
2.6.1. Use a Scale
2.6.2. Crearte experience-based table
2.6.2.1. Specify risk rates
2.6.2.1.1. Make risk calculations
2.6.3. Set up min and max estimating hours
2.6.4. Set up average estimating time
2.6.5. Insert proper data in Estimation table
3. Risks
3.1. FACTS
3.1.1. "Shit happens" (by Forrest Gump)
3.1.2. Murphy's law says...
3.1.3. "...if defects did not exist then neither would testing"
3.2. General Points
3.2.1. Likelihood
3.2.1.1. Captures the idea that something is likely to happen or to have happened
3.2.2. Impact
3.2.2.1. Measure of negative or positive consequences on the project in case of some risks happen
3.2.3. Risk Exposure
3.2.3.1. Risk Exposure = Likelihood * Impact
3.3. Types of Risks
3.3.1. Project Risks
3.3.1.1. Supplier issues (third party issues)
3.3.1.2. Organisational factors (skills, stuff problems, bad management, political issues, communication problems)
3.3.1.3. Technical issues (requirements, environment, test tools/data, low quality of code/tests/configurations )
3.3.2. Product Risks
3.3.2.1. Poor software characteristics (e.g. functionality, security, reliability, usability, performance)
3.3.2.2. Poor data integrity and quality (e.g. data migration issues, data conversion problems, data transport problems, violation of data standards)
3.3.2.3. Software that does not perform its intended functions
3.3.2.4. The potential that a defect in the software/hardware could cause harm to an individual or company
3.4. Risk Control
3.4.1. Identification
3.4.1.1. - Expert interviews - Independent assessment - Use risk templates - Project retrospectives - Risk workshops - Brainstorming - Checklists - Calling on past experience
3.4.2. Assessment
3.4.2.1. Create Risks Exposure table
3.4.3. Reaction
3.4.3.1. Negative
3.4.3.1.1. Avoidance
3.4.3.1.2. Third-party delegation of reponsibility
3.4.3.1.3. Reduction
3.4.3.1.4. Acceptance
3.4.3.2. Positive
3.4.3.2.1. Use (realize appropriate possibility)
3.4.3.2.2. Third party support to realize appropriate possibility in the best way
3.4.3.2.3. Increase positive consequences
3.4.3.2.4. "smile and wave boys"
3.4.4. Management
3.4.4.1. Monitor the risks
3.4.4.2. Find and specified new types of risks
3.4.4.3. Analyse the reasons
3.4.4.4. Change our strategies and plans
3.4.4.5. Add new risk into the Risk Register database
3.5. Risk Strategies
3.5.1. Fixing (reduce the likelihood or reduce the impact)
3.5.2. Monitoring
3.5.3. Delegating
3.5.4. Accept (nothing to do)
3.6. Risks in QA
3.6.1. Deployment risks
3.6.2. Requirements change too often
3.6.3. Lack of environment
3.6.4. Unrealistic environment
3.6.5. Tests supporting problems
3.6.6. Bad estimations
3.6.7. Insufficient test covering
3.6.8. Lack/decreasing of resources (budget, stuff, etc)
3.6.9. Absence of documentation
3.6.10. Development is continued after "freezing"
3.6.11. Uncontrolled increase in the volume of work
3.6.12. Ad-Hoc testing on Production