Agile+Estimating

Introduction
toc Agile estimating is an agile practice, critical to the success of any software development project. It is a process of transforming requirements, skills, people and equipment into how much the project will cost and how much effort it will take, This whole process is bond by a cone of uncertainty. I n the early days of software development, lines of codes were used to measure the size of products but in recent times, estimation duration of software projects are derived from desired features and estimation size. In agile estimation there are three main concepts that are required namely:
 * **Estimation of Size: ** This is usually done using story points.
 * **Velocity ****: T**his is the measure of a team’s rate of progress. It refers to how many points the project team can deliver within an iteration.
 * **Estimation of Effort: ** This is where days or hours are used to estimate the actual time.



Definition of Agile Estimation
Cohn (2006) considers that estimating and planning are vital to the success of project of any size or result. Estimation and plans help us know the resources necessary to work on a project during a given period. Managers can use them to test if a project meets the functionality those users need and expect. Yet estimating and planning are difficult and error prone. According to Cohn (2006), if the project could complete estimates later, it will get more accurate than early. The purpose of estimating and planning is to find an optimal level for the entire product development. The optimal scheme consist of a planning process that reduces risk, reduces uncertainty, supports reliable decision making, establishes trust, and conveys information (Cohn, 2006).

Techniques of Agile Estimation
 Estimation scales can be chosen based on their magnitude. This includes: Mike Cohn (2006) suggests that there are three agile estimating techniques which includes the following:  **Expert option:** This technique relies solely on the intuition or gut feel of an expert in estimating the duration of a project. **Estimate by Analogy:** Estimation is based on a comparison between user stories using a process called triangulation  **Disaggregation:** During estimations stories are broken down into smaller units, this makes estimation easier.  **Planning poker game:** This method combines all the above mentioned three techniques into one.During a poker game, participants are divided into groups with each group having its own developers and estimator. The story points are estimated based on the figure in the poker cards provided by the developers. A major limitation of the poker game is the unequal level of knowledge among the estimators.
 * <span style="font-family: Arial,sans-serif;">1, 2, 3, 5 and 8 (Fibonacci sequence) <span style="background-color: white; font-family: Arial,sans-serif;">Number increases by sum of itself and the previous.
 * <span style="font-family: Arial,sans-serif;">2, 4 and 8 <span style="background-color: white; font-family: Arial,sans-serif;">Each number is twice the multiple of number preceding it.
 * 0 = a valid number in estimating range

**<span style="font-family: Arial,sans-serif;">Why Agile estimation works **

 * <span style="font-family: Arial,sans-serif;">Estimates are done by the actual workers: These are the developers that will be carrying out the tasks. It makes sense that they give estimations of the duration of the tasks as the customer is guaranteed that estimation is coming from the right people
 * <span style="font-family: Arial,sans-serif;">Customers can ask for estimate justification: Customers get good knowledge of cost and duration for tasks because they can ask estimators to justify estimations
 * <span style="font-family: Arial,sans-serif;">Estimates come from experts: Estimates are derived from a combination of individual estimations of experts that will carry out the tasks and through group discussions. This leads to better estimations
 * <span style="font-family: Arial,sans-serif;">Estimates are relative and not absolute: This makes it possible for estimates to be changed if necessary
 * <span style="font-family: Arial,sans-serif;">Estimates are constrained: Agile estimates are constrained by the values attached to them
 * <span style="font-family: Arial,sans-serif;">Every opinion counts: Everyone that will be involved in the task has a say in estimation. This increases team cohesion during estimations
 * <span style="font-family: Arial,sans-serif;">Estimating is quick and fun: It is quick, fun and encourages familiarity between customers and project team members

Story Points Vs Ideal Days

 * **Story Points help Drive Cross Functional Behaviou**r:because the estimation is a single number representing the work of the whole team while estimating in ideal days represent estimation of a speciality group only i.e. programmer.
 * **Story Points Do not Decay**: estimates in story points has a longer shelf life because it does not change while the estimates in ideal days change regularly based on the team's experience with technology
 * **Story points are a pure measure of size:** because estimates in story points takes in to account the size and how much of it that needs to be done first before estimating while estimating in ideal days changes because it compares ideal days with actual days
 * **Estimating in Story Points are Faster**: teams estimating in story points do so more quickly because high level discussion about the story takes place from the onset while ideal days takes discussion a little deeper thus making estimation longer
 * **My Ideal Days are not your Ideal Day**
 * **Ideal Days are Easier to Estimate at First**: It is easier than to get started with estimating in ideal days than in story points
 * **Ideal Days are Easy to Explain Outside the Team:** because estimates in ideal days are easier to understand by everyone on the team and outside of the team while estimates in story points are not