File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Agile and Other Processes and the fly likes Estimation in Agile Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Estimation in Agile" Watch "Estimation in Agile" New topic

Estimation in Agile

Pankaj Kumarkk
Ranch Hand

Joined: Apr 17, 2011
Posts: 110
I have question on the way estimations are done in Agile. I work in a team which follows agile. Typically the tasks are estimated by the developers without any basis (and more of gut feel). e.g let's say that there is a task "task1" to be done. Developer "X" may take it up and says that it can be done in 2 days. Another developer may do it in 1 day.
How do you justify this. Isn't it unfair that that people who overestimate aren't differentiated from people who give genuine estimate. I am struggling to find a a solution for this. or is this something normal in agile and there is no need to look for a solution for this.
I am looking for opinion from other people who run agile projects. How do you tackle this in your project.

Arnold Reuser
Ranch Hand

Joined: Nov 20, 2003
Posts: 196
Two practical tips :
* Are you guys already applying planning poker? Usually it is just one or a few developers really over- or under estimating a task. The rest often have a clearer view on what's expected.
* Already heard of backlog refinement meetings? One of the lesser known, but valuable, guidelines in Scrum is that five or ten percent of each Sprint must be dedicated by the team to grooming the Product Backlog.
In practice a regularly scheduled weekly meeting with the Product Owner is enough for experienced Teams to estimate user stories. In your case, it will help you get a first rough cut of the estimation process.

Madhan Sundararajan Devaki
Ranch Hand

Joined: Mar 18, 2011
Posts: 312

You may use standard estimation techniques (for example "Function Points"), to solve your problem.

Not many get the right opportunity !
deepak adlakha
Ranch Hand

Joined: Jul 27, 2001
Posts: 325
I can understand this can be problem. there is option of like bench marking. After one two Iterations make some baseline like Task A is similar to what we did in previous Iteration and that took x amount so same will take X amount. I understand it can be little tough as individual domain knowledge or expertise. but then at the end of Team needs to be comfortable with the Estimates.
Anirudh Bhatnagr

Joined: Sep 01, 2010
Posts: 12
Thats what the whole concept of Agile Estimation lies..
Obviously any two people will have different speeds of doing work.
Simple dynamics, So if you are going to estimate time, you would need speed and speed varies person to person.

Estimate in size and relative complexity or past experience and assign a weight or story point to it.
Have every one involved in this process, Use planning poker if you feel.

Then break up the user stories into tasks.Perhaps each person can take up tasks and estimate his/her time.
First couple of sprints you can give the levy to the team to find the velocity range then you can plan your sprints further.

Watch this video by Mike Cohn at google :
Pat Farrell

Joined: Aug 11, 2007
Posts: 4659

Madhan Sundararajan Devaki wrote:You may use standard estimation techniques (for example "Function Points"), to solve your problem.

I love it. Function Points is right up there with KLOC as a known terrible metric.
I agree. Here's the link:
subject: Estimation in Agile
jQuery in Action, 3rd edition