What are different techniques for estimating used by agile teams?

Expending more time and effort to arrive at an estimate does not necessarily increase the accuracy of the estimate. The amount of effort put into an estimate should be determined by the purpose of that estimate. Although it is well known that the best estimates are given by those who will do the work, on an agile team we do not know in advance who will do the work. Therefore, estimating should be a collaborative activity for the team.

Concepts on Estimating

- Agile teams acknowledge that we cannot eliminate uncertainty from estimates, but they embrace the idea that small efforts are rewarded with big gains.
- Agile teams can produce more reliable plans because they frequently deliver small increments of fully working, tested, integrated code.
- Agile teams do not rely on single expert to estimate. Estimates are best derived collectively by the team.
- Estimates should be on a predefined scale.
- Features that will be worked on in the near future and that need fairly reliable estimates should be made small enough that they can be estimated on a non-linear scale from 1 to 10 such as 1,2,3,5, and 8 or 1,2,4, and 8.
- Larger features that will most likely not be implemented in the next few iterations can be left larger and estimated in units such as 13,20,40, and 100.
- Some teams choose to include 0 in their estimation scales.

Four common techniques for estimating are:

1. Expert Opinion
- In this approach, an expert is asked how long something will take or how big it will be.
- The expert relies on his/her intuition or gut feel and provides an estimate.
- This approach is less useful on agile projects as compared to traditional projects.
- In an agile project, estimations are made on user stories or other user-valued functionality. It requires lot of skills by more than one person which makes it difficult to find suitable experts.
- Benefit of expert opinion is that it does not take very long.

2. Analogy
- In this approach, the estimator compares the story being estimated with one or more other stories.
- If story is twice the size, it is given estimate twice as large.
- You do not compare all stories against a single baseline, instead, each story is estimated against an assortment of those that have already been estimated.

3. Dis aggregation
- It refers to breaking a story or feature into smaller, easier to estimate pieces.
- Be careful not to go very far with this approach.

4. A fun and effective way of combining these is planning poker.
- In planning poker, each estimator is given a deck of cards with a valid estimate shown on each card.
- A feature is discussed, and each estimator selects the card that represents his or her estimate.
- All cards are shown at the same time.
- The estimates are discussed and the process repeated until agreement on the estimate is agreed.

A general overview of software estimation techniques...

Few things should be kept in mind while the software project planner begins the project:
- how long will it take?
- how much effort is required?
- how many people are involved?
- what resources are required?
- what kind of risk is involved?
The statement of scope helps the planner develop estimates using one or more techniques that fall into two broad categories:
- decomposition
- empirical modeling.

Decomposition techniques require a delineation of major software functions followed by estimates of either:
- the number of lines of code.
- selected values within the information domain.
- number of use cases.
- number of person months required to implement each function.
- number of person months required for each software engineering activity.

Empirical techniques use empirically derived expressions for effort and time to predict these project quantities. Automated tools can be used to implement a specific empirical model.

By comparing and reconciling estimates derived using different techniques, the planner is more likely to derive an accurate estimate. Software project can never be an exact science but it is a combination of good historical data and systematic techniques that helps in improving estimation accuracy.

Testing activities in Requirements Analysis phase

The following test activities should be performed during this stage :
- Invest in analysis at the beginning of the project.
Having a clear, concise and formal statement of the requirements facilitates programming, communication, error analysis and the test data generation. The requirements statement should record the following information and decisions :
+ Program function - what the program must do?
+ The form, format, data types and units for input.
+ The form, format, data types and units for output.
+ How exceptions, errors and deviations are to be handled?
+ For scientific computations, the numerical method or at least the required accuracy of the solution.
+ The hardware and software environment required or assumed.
Deciding the above issues is one of the activities related to testing that should be performed during this stage.

- Start developing the test set at the requirements analysis phase
Data should be generated which can be used to determine whether the requirements have been met. To do this, the input domain should be partitioned into classes of values that the program will treat in a similar manner and for each class a representative element should be included in the test data. In addition, following should also be included in the data set: boundary values, any non-extreme input values that would require special handling. The output domain should be treated similarly. Invalid input requires the same analysis as valid input.

- The correctness, consistency and completeness of the requirements should also be analyzed.
Consider whether the correct problem is being solved, check for conflicts and inconsistencies among the requirements and consider the possibility of missing cases.