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.

How does agile teams work?

Agile teams work together as a team but include roles filled by specific individuals.
- First is the product owner, who is responsible for the product vision and for prioritizing features the team will work on.
- Next is the customer, who is the person paying for the project or purchasing the software once it is available.
- Users, developers, and managers are other roles on an agile project.

How does agile team work?

- Agile teams work in short, time-boxed iterations that deliver a working product by the end of each iteration.
- The features developed in these iterations are selected based on the priority to the business.
- This ensures that the most important features are developed first.
- User stories are a common way for agile teams to express user needs.
- Agile teams understand that a plan can rapidly become out of date. Because of this, they adapt their plans as appropriate.

What kind of planning are used for agile teams?

Agile teams use three levels of planning:
- Release planning : The release plan looks ahead for the duration of the release - typically, three to six months.
- Iteration planning : The iteration plan looks ahead only the duration of one iteration - typically, two to four weeks.
- Daily planning : A daily plan is the result of team member commitments made to each other in a daily stand-up meeting.

During release planning, the whole team identifies a way of meeting the conditions of satisfaction for the release, which includes scope, schedule, and resources. To achieve this, the product owner may need to relax one or more of her conditions of satisfaction.
A similar process occurs during iteration planning, when the conditions of satisfaction are the new features that will be implemented and the high level test cases that demonstrate the features were implemented correctly.