Estimation methods for software development are of high concern for both the customer and the provider.  Any software development project starts with mapping together the conditions of running the processes. Requirements of time, budget, quality and efficiency will be coupled with given infrastructure, human resources, security and business continuity features.

Software project size estimation is a difficult activity, and its’ results should constantly be updated with actual counts throughout the life cycle. According to worldwide practices, size measures include source lines-of-code (LOC), function points (FP), and feature points.

At Codespring we mainly use the following methods:

  • Function Points Estimations
  • Two Step Estimations

Function Points Estimations

We start defining the User Stories (or features specifications). We classify the User Stories by difficulty degree expressed in Story Points. This is being done through the Planning Poker or Scrum Poker method.

User Stories are broken down into tasks and a second classification is made. The story Points are being converted in hours based on the team involved in the planning phase. Thus, the estimation of the number of User Stories solvable in a certain time frame is being obtained.

Benefits:

  • The method reduces anchoring;
  • Estimations can be released faster and includes the experience of each team member;
  • It is adequate for Agile Development;
  • Provides best results when the User knows what is the desired outcome;

Two Step Estimations

Step 1: Definition Estimation

At this stage the goal is to define what and how the software will look like. Functional Specifications (FS), Requirements specifications (RS) and a rough Architecture will be drafted.

Step 2: Implementation Estimation

When the project is defined, the detailed architecture and tasks breakdown can be done. The result will be: number of development hours, team size and final price.

Benefits:

  • This method is useful when the project is not defined. Documentations and Requirements must be created;
  • In this case the time for communications, meetings, testing, integration, deployment, documentation and training are being considered;

Complexity is a function of size, having a major impact on design errors and latent defects. In order to prevent quality problems, cost overruns and schedule slips, complexity must be continuously measured, tracked, and controlled.

Diligent control of the overall process will reduce estimation inaccuracies and will get the project closer to the reality.