How do we estimate in Agile?

 Posted by ArticlesMaint on 9/30/2009 | Category: Project Management Interview questions | Views: 17930

If you read the Agile cycle carefully (explained in the previous section) you will see Agile estimation happens at two places.

• User Story Level Estimation: - In this level a User story is estimated using Iteration Team velocity and the output is Ideal Man days or Story points.

• Task Level Estimation: - This is a second level of estimation. This estimation is at the developer level according to the task assigned. This estimation ensures that the User story estimation is verified.

Estimation happens at two levels one when we take the requirement and one when we are very near to execution that’s at the task level. This looks very much logical because as we are very near to complete task estimation is more and more clear. So task level estimation just comes as a cross verification for user story level estimation.

Figure: - Agile Estimation

User Story Level Estimation

Estimation unit at user story in Agile is either “ideal days” or “Story points”.

Ideal days are nothing but the actual time the developer spent or will spend on only coding. For instance attending phone calls, meetings, eating lunch and breakfast etc are not included in the ideal days. In old estimation technology we estimate eight hours as the complete time a developer will do coding. But actually a developer does not code continuously for eight hours, so the estimates can be very much wrong if we consider the full eight day hours.

Estimation units can also be represented in story points. Story Points are abstract units given to represent the size of the story. In normal scenario one story point equals to one ideal day. Story point is a relative measure. If one story is one story point and the other is two story points that means the second story will take twice the effort as compared to the first story.

Velocity determination defines how many user stories can be completed in one iteration. So first the user decides the length of the iteration. Length of iteration is decided depending on the release dates. Velocity is normally determined from history. So what ever was the last team history velocity same will be used in the further estimation. But if there is no history then the below formulae will be used:-

Figure: - Velocity Determination

There are two formulas in the above figure the first formula is used when we do not have history about the project and the second formulae is when we have a history of the iteration. Below are the details of all the parameters in the formulae:-

• Number of developers: - Total Number of developers in the iteration.
• Load factor: - This means how much productive time a developer will spend on the project. For instance if the load factor is 2 then developers are only 50% productive.
• How long is the iteration in business days: - One iteration is of how many man days.

Below figure ‘Iteration and Release calculation’ shows a simple sample with a team size of 5, load factor of 2, one iteration takes 11 business days and there two releases in the project.

Figure: - Iteration and Release calculation

Task Level Estimation

As the Agile cycle moves ahead user story is broken down in to task and assigned to each developer. Level of effort at the task level is a form of Task points or Ideal hours. Ideally one task point represents one ideal hour. Ideal hour is the time when developer spends only on coding and nothing else.

Individual Velocity determination defines how many how many ideal hours a developer has within one iteration. Below figure ‘Individual Velocity Calculation’ shows in detail how to get the number of ideal hours in iteration for a developer. Below is a sample calculation which shows with 8 hours a day , iteration of 11 days and load factor of 2 ( i.e. developer code for only 50% time i.e. 4 hours) , we get 44 ideal hours for developer in that iteration.

Figure: - Individual Velocity Calculation

Asked In: Many Interviews | Alert Moderator 

Comments or Responses

Login to post response