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.
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.
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.
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.