Get certified - Transform your world of work today

Risk Estimation During Agile Project Planning

01/09/2014 by David Caicedo

Recently we performed a workshop to estimate the total number of sprints that a specific software implementation will take us.

At the end of this session, I asked myself how we could estimate the risk percentage, to add it to the actual estimation. Based on this, we determined that the possible risk causes are divided into five areas: acquisition, supply, development, support, and organizational.

In order to solve the Acquisition area, we defined the following questions:

  Acquisition Value Risk
1 The product owner has a defined vision of what is needed. Good 5
2 The product owner is committed and gets involved with the team. Yes 0
3 The product owner knows all the principles of Agile development. Theory 6
4 Previously, or during the first sprint, an acquisition analysis has to be done. No 5
5 The acquisition model of the client allows a pattern of Agile development. Yes 0
6 The innovative value comes from the priority of the clients business, over a closed product plan. Yes 0
Total Value 16

The Value column has various options, but only one can be chosen, and it will have a certain weight previously assigned.

The maximum total value that this area can have is defined by the addition of all the risk in the worst-case scenario, which will total 72.

To sum up, the risk indicator for this particular area is 16/72 = 0.22. This means that the risk factor is 22.22%. The percentage values have been grouped in the following manner:
0-39 = low
40-69 = medium
70/72 = high

For the following areas, we asked the questions shown below:
  Supply Value Risk
1 The type of contract is adequate for a model of iterative and incremental development. Yes, with repairs 3
2 The team consist of experts in the different areas and has enough knowledge to carry on with the software development. Yes, with repairs 5
3 The product owner monitors the feedback information (business environment, Scrum meetings feedback, etc.). Yes 0
4 The one responsible for the team coordination has experience in Agile development. Theory 8
Total Value 16

  Development Value Risk
1 The team knows about the model of Scrum development. Expert 0
2 The team has experience in estimating tasks. Little 4
3 The team has experience in the technology and platform it will work on. Normal 10
4 The team’s technical level is high. Most are junior 15
5 The team is cooperative and cohesive. Yes 0
6 Scrum routines are performed in a standardized manner. Yes 0
Total 29

  Support Value Risk
1 The team has adequate means to provide support to the product backlog. Yes, with repairs 5
2 The team has adequate means to provide support to the sprint backlog, as well as the monitoring of the sprint evolution. Yes, with repairs 5
3 The product owner can monitor the product evolution. Yes, with repairs 5
4 The team has all the adequate technical means for the programming tasks. Yes 0
Total 15

  Organizational Value Risk
1 The team has all the adequate infrastructure: meeting rooms, teams and development tools, etc. Yes 0
2 The company considers the selection and the incorporation of the employees a key process to get the best results possible. Prioritized 10
3 The company considers the employee information a key way to increase the quality of the results. Very high priority 0
4 The whole company knows the principles of Agile development and is committed to its implementation and correct functionality. Formal only compromise 10
Total 20

Last, using the results, an indicators table can be elaborated, as shown below:
  Risk Values
AREA Acquisition Supply Development Support Organizational TOTAL
Total 16 16 29 15 20 96
Maximum 72 49 90 45 88 344
Percentage 22.222222 32.653061 32.222222 33.333333 22.727272 143.15811

Summing up all the result horizontally, we can obtain the total results.


Apparently our risk is low; nevertheless its value is 28%. The highest risk value is found in the Support column. This allows us to identify in advance the actions that will let us control this aspect.

This is an easy and practical way to define the areas that might be affected during the execution of the project, as well to perform a calculation of their possible risk values.