Estimating with Use Case Points - FREE template

Being lazy, I was looking for a free, read-made, comprehensive and easy-to-use spreadsheet template for estimating project effort with use case points. I needed it for one of my current projects, in which we are writing 200+ use cases (sic!, see my remark below), and prepare a project proposal for senior management. 

I came across Scott Selhorst's material on Use Case Point Estimation. Very useful!

Check out:

• An introduction to use case point estimation with good context for use case newbies
  
• A How-to for the final calculations
  
• The free template
  

The template can also be googled and found at modernAnalyst, another useful source of information for business analysts and such folk.

Note on the large number of use cases: I personally think they are no real use cases. It's quite close to a functional decomposition done in use case form. I expect the system to arrive at about 8000 Function Points, but estimates range from 1.000 to 15.000 as of now :-)

 

Earned Value Analysis for Feature-Burndown in Iterative Projects

Name: Earned Value Analysis for Feature-Burndown in Iterative Projects
Type: Process
Status: final
Version: 2008-03-27

Gist: to explain how to obtain information about the Earned Value of an agile project that is using a backlog of either {user stories, features, requirements, change requests}

Source: T. Sulaiman, H. Smits in Measuring Integrated Progress on Agile Software Development Projects. In addition, there's tons of information out there on Earned Value Analysis, check out:
http://en.wikipedia.org/wiki/Earned_value_management
www.earnedvalueanalysis.com/
www.projectlearning.net/pdf/I2.1.pdf

feature FOR THIS POST DEFINED AS a thing to be implemented, could well be a requirement, a user story, a use case. Whatever your backlog consists of.

Entry-Conditions:
E1: Each feature in your backlog needs to have an estimate, best measured in some points, gummy-bears etc. (Make the sum of all features your parameter TSPP, total sum of planned feature points)
Note: It's not imortant that these estimates represent actual budget, time or similar. They have to be consistent with each other and represent properly the relative relations between them
Note: You can adjust the number later but you will have to recalculate things (see S3-S5).
E2: You need to know how many iterations you will undertake. (Make this your parameter TNI, total number of iterations).
Note: Ideally, iterations are all the same length, i.e. timeboxes. You can adjust the number later but you will have to recalculate things (see S3-S5).
E3: You need to know the budget you are about to spend, from now to the end of the last iteration (make this your parameter TBP, total budget planned).
E4: You need an established way of tracking how much budget you have actually spent on each of the iterations.
Note: This can be obtained by maintaining a log of workhours spent on the project by each of its members.

Process:
S1: After every iteration, find out how much budget you have actually used for the iteration. Sum it up over all finished iterations. Make this your ABS, actual budget spent
S2: After every iteration, find out how many points you have actually implemented within all iterations (= ASI, actual sum implemented). All the feature's points count as implemented if and only if the feature is in full effect.
Note: this means you have to have a clear understanding what 'done' means for a feature.

S3: Do some calculations
- Expected Percentage Completed = TNI / number of already finished iterations
- Actual Percentage Completed = TSPP / ASI
- Planned Value = TBP * Expected Percentage Completed
- Earned Value = TBP * Actual Percentage Completed

S4: Find out about you projects cost performance and cost estimate:
- Cost Performance Index = Earned Value / ABS
Note: > 1 means under budget, = 1 means on budget, < 1 means over budget
- Cost Estimate to Completion = TBP / Cost Performance Index

S5: Find out about you projects schedule performance and schedule estimate:
- Schedule Performance Index = Earned Value / Planned Value
Note: > 1 means before schedule, = 1 means on schedule, < 1 means behind schedule
- Schedule Estimate to Completion (in iterations) = TNI / Schedule Performance Index

Effort Needed for Product Enhancements

Name: Effort Needed for Product Enhancements
Type: RuleSet
Status: finished
Version: 2007-05-04

Gist: Calculate Effort from # of Function Points, for Enhancements

R1: The Capers Jones Formula for Effort E of new Products (in person months): E = (# Adjusted Function Points)^1,4 / 150
R2: Enhancements of products cannot be calculated with the same formula, as you need to take into account that you add complexity to an existing product.
R3: Formula for the needed EnhancementEffort EE for an Enhancement of y function points to a a base product of y function points:
EE = E(x+y) - E(x)
Note: Obviously you need to know y and x. The greater x is, the more significant is the difference between E and EE.

Testcase Numbers based on Function Points

Name: Testcase Numbers based on Function Points
Type: RuleSet
Status: finished
Version: 2007-05-04
Source: Internet, IFPUG-Website, Capers Jones

Gist: Calculate the number of test cases for a reasonably tested product.

R1: # of test cases = (# adjusted function points)^1,2
R2: # of acceptance tests = (# adjusted function points) * 1.2

Principles of Clear Thinking

Type: Rules
Status: Draft
Version: 2007-12-20
Quelle: Principles of Clear Thinking. <- Blog on http://www.blogger.com/www.gilb.com 2007-03-27 (R1 to R10); rest: own thoughts
R1. You have to have a clear set of objectives and constraints, to evaluate proposed solutions or strategies against.
R2. You have to have a reasonable set of facts about the benefits and costs of any proposed idea, so that you can relate it to you current outstanding requirements.
R3. You have to have some notion of the risks associated with the idea, so that you can understand and take account of the worst possible case.
R4. You have to have some ideas about how to test the ideas gradually, early and on a small scale before committing to full scale implementation.
R5. If there are more than very few factors involved ( 2 to 4) then you are going to have to use a written model of the objectives, constraints, costs, benefits, and risks.
R6. If you want to check your thinking with anyone else, then you will need a written model to safely and completely share your understanding with anyone else.
R7. You will need to make a clear distinction between necessities (constraints) and desirables (targets).
R8. You will need to state all assumptions clearly, in writing, and to challenge them, or ask ‘what if they are not true?’
R9. You will want to have a backup plan, contingencies, for the worst case scenarios – failure to fund, failure for benefits to materialize, unexpected risk elements, political problems.
R10. Assume that information from other people is unreliable, slanted, incomplete, risky – and needs checking.
R11. Assume that you models are incomplete and wrong, so check the evidence to support, modify or destroy your models.