Introduction



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. In 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: This 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.

estimate.jpg
Size, Velocity and Duration in Agile Estimation (Cohn, 2008)



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:
  • 1, 2, 3, 5 and 8 (Fibonacci sequence) Number increases by sum of itself and the previous.
  • 2, 4 and 8 Each number is twice the multiple of number preceding it.
  • 0 = a valid number in estimating range
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.


Why Agile estimation works


  • 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
  • Customers can ask for estimate justification: Customers get good knowledge of cost and duration for tasks because they can ask estimators to justify estimations
  • 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
  • Estimates are relative and not absolute: This makes it possible for estimates to be changed if necessary
  • Estimates are constrained: Agile estimates are constrained by the values attached to them
  • Every opinion counts: Everyone that will be involved in the task has a say in estimation. This increases team cohesion during estimations
  • 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 Behaviour: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


References

Cagley,T. (2009) Agile Estimation using Functional Metrics. Available Online at: http://www.outsourcemagazine.co.uk/downloads/agile_estimation_using_functional_metrics.pdf [Accessed on 5 May, 2012]
Cohn, M. (2006) Agile Estimating and Planning. London: Pearson Education.
Cohn, M. (2008) Agile estimating and planning. Available Online at: http://www.mountaingoatsoftware.com/system/presentation/file/92/ADP08_AgileEstimatingAndPlanning.pdf. [Accessed on: 23 March, 2012]
Rubin, K. (2006,2007) Agile Estimating; Innolution llc and mountaingoatsoftware Inc Available Online at:www.Innolution_Agile_Estimating_Rubin(1).pdf-Adobe Reader [Accessed on 5May, 2012]

To Plan ,To Schedule ,To Hire,To Price