Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Estimation in Agile

 
Pankaj Kumarkk
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Satish
 
Arnold Reuser
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 312
Java MS IE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may use standard estimation techniques (for example "Function Points"), to solve your problem.
 
deepak adlakha
Ranch Hand
Posts: 325
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 :
http://www.youtube.com/watch?v=fb9Rzyi8b90
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic