Affinity Estimation

Affinity Estimating is a technique many agile teams use too quickly and easily estimate a large number of user stories in story points. This is a great technique if a project has just started, and have a backlog that hasn’t been estimated yet, or in preparation for release planning.

Characteristics of agile affinity estimation:

1) Quick and Easy

2) Make decision fairly transparent and visible

3) Create a positive and collaborative experience rather than confrontational exercise in estimation session.

Participants of agile affinity estimation:

1) Product Owner of a project

2) Delivery agile Team

3) Scrum Master to facilitate

Various steps involved in affinity estimation are:

Silent Relative Sizing:

The product owner provides the user stories to the team and the agile team silently establishes the relative sizes of the user stories. The team arranges the stories in ascending order on a horizontal scale. It may also be done by re-arranging notes or index until the entire team is satisfied with the order. This step is performed “silently” as in mute-mapping, to keep the process quick and non-confrontational.

Editing the wall:

The team members edit the relative sizes on the wall. This step involves discussions between the product owner and the team and the later can optionally rearrange the order that was decided in the first step based on their relative discussion and decision.

Placing items into relative sizing buckets:

The items are placed in definite “buckets” which are labelled according to the estimation scale of choice. For example, the buckets can be labelled as Extra Small, Small, Medium, Large and Extra Large or it may be labelled based on a non-linear scale with story point values such 1, 2, 3, 5, 8 and 13.

Product owner challenge:

The product owner in this step may discuss the sizes with the team. If the team does decide to change the size of a story, they first remove it from the wall and then place it according to the revised size that they arrive at, based on discussions with the product owner.

Storing the data:

After the entire team finalizes the estimates, the data is stored and the affinity estimation is documented. After the completion of this step the process of affinity estimation is considered complete.

Cost / Budget Estimations

Two basic questions that in general anyone may ask are:

• Where do project cost estimates come from?

• How do I even get started creating a budget?

The budget is the financial presentation of major cost categories specified by the sponsor. The purpose of an estimate in the corporate world is to enable the sponsor to set aside a budget for the entire initiative, not just the current iteration. This estimating task is also not that baffling, either. As iterations are time-bound, entire projects are both time-bound and cost-bound. The client sets the budget that regulates the features that will be included in the project. In agile world, team starts with the sponsor's available budget and then determines what can be delivered within that budget. Cost budgets allocate portions of the total to individual tasks. Than based on team velocity we calculate budget allocated in each iteration

• Example: 7 team members working at a billable rate of $500/day.

It is estimated that the project will need 20 iterations to complete with 10 days per iteration.

What is the cost of the project?

• Cost per engineer for 10 days = 10 * 500 = $5000

• Cost per iteration = per engineer cost * number of engineers

• = $ 5000 * 7 = $ $35, 0000

Total Cost = $ 35,000 * 20 = $ 700,000

Conclusion

There are three main concepts you need to understand to do agile estimation. Estimation of Size gives a high-level estimate for the work item, typically measured using a neutral unit such as points. Velocity tells us how many points this project team can deliver within an iteration. Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take the team member(s) to complete the assigned work item(s). Estimation cannot be made perfect. Smaller items are easier to estimate than larger items. Taking more time does not always mean that estimates are more accurate. Estimation errors do not cancel, but accumulate. The process must take uncertainty into account. Discussion of high-low results forces assumptions, issues to surface.