Take the tour ×

My manager asked me to write a estimation of work hours and a risk estimation of source code changes for a defined task.

While the first is no problem for me and there are many resources on the web, I cannot get my head around the latter one.

I already asked for a clearer description of risk estimation and got the answer that the risk for the need of "follow-up code changes due to the changes made" and "potential loss of stability of the overall software" should be stated.

How can I approach this task (thumb rules, documents about risk estimation, ...)?

share|improve this question
See PM@SE site: pm.stackexchange.com Especially: pm.stackexchange.com/questions/tagged/risk –  Mchl Jul 5 '11 at 10:52
Some sources says on average there are 15-50 defects per 1000 lines of code, so if you can estimate how much you're about to add/change, that might be something. Not useful (risk estimates rarely is), but at least it's some kind of number that might keep them of your back. –  Martin Wickman Jul 5 '11 at 12:36
add comment

3 Answers

up vote 4 down vote accepted

Your manager doesn't want numbers for the risks.

A manager usually wants to know you won't mess the software up.

The two risk areas amount to "do you know everything you need to know?" and "will you break anything else?"

You should probably give a qualitative analysis of the risks.

List the questions you have -- the mysterious areas -- the things that might require follow-up or that you might break because you don't understand them.

The "numbers" are 1.0. You will have follow-up changes (there are always follow-up changes) and you will introduce new previously unknown bugs (unless you have a really good testing discipline, which sounds unlikely from the situation and the question).

Ideally, you understand the whole problem and won't need follow up. Is this really true? What evidence can you give that you understand everything? If you have evidence, present it and claim that there's no risk of follow-up. If you don't have evidence that you understand the whole problem, list the things you don't understand. That's the risk.

Ideally, you won't break anything else. Is this really true? What evidence can you give that your change is isolated and you won't break anything else? Again, list the things that might break; that's the risk.

Note that perfect knowledge can only come after you've actually completed all the changes. Only after you make the code change, you'll know whether or not you knew everything and didn't break anything else.

Looking into the unknowable future, you can only guess if you know everything and won't break anything.

Consequently, there's a level of diminishing returns. You can provide some evidence that you understand the change and won't break anything, but you can't be absolutely sure of your analysis except by actually making the actual code change.

share|improve this answer
+1 for dangerous amounts of common sense! –  maple_shaft Jul 5 '11 at 11:33
add comment

The best place to start would be with some concrete examples. Choose a few areas of your application and work out the cost of something going wrong in that area and the likelihood of it happening.

For example, if you made a change to the login process the costs might be:

  1. Users not being able to log on.
  2. Anybody being able to gain access.
  3. Users logging on but not having access to the correct functionality - i.e. they have the wrong role.

The likelihood of each is then assessed:

  1. Unlikely - you'll pick this up in testing quite quickly.
  2. Unlikely - again this is (or should be) easy to pick up.
  3. More likely - depending on how complex your application is spotting that someone has access to something they shouldn't or doesn't have access to something they should is harder to spot.

So the need for "follow up code changes" and the "potential loss of stability" for the first two is low (but will still exist), while for the third is higher.

Once you've done this for some high and low risk areas you'll be able to assign anything into one of these areas.

share|improve this answer
add comment

While I feel "Risk Estimation" is mostly a bad metric, it is even worse if given to a developer, especially the very developer who will be doing work. Your manager might as well ask you to single-handedly do your own acceptance testing and your own code review as well.

If there is a right way to do risk analysis for a task or feature I would do so by a few measures:

  1. How many independent components or function points does the feature touch?
  2. Do the affected features or components have clear and complete design documentation or technical specifications?
  3. Are there affected features or components covered by automated unit tests?
  4. What other measures of technical debt are strangling the system that could be problematic?

Perhaps if you can numerically account for these kinds of things and formulate them in some kind of BS forumla to determine a ratio of risk, your manager will probably be happy with that. Formulas like the one I described, while mostly meaningless, are like Managerial Porn.

share|improve this answer
add comment

Your Answer


