Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

howto estimate story effort

 
enric jaen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

I know that estimation is relative to others stories.

but as a programmers, which criteria do to you use to estimate the effort of a story?

i.e. how do you determine the amount of work a given story requires?




for example, given the javaRanch application:

"as a user, I want to log into the JavaRanch system before to post a topic"

"as a user, I want to create a new topic"

which criteria do you follow to determine their relative effort?


 
Mathieu Fortin
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It takes time and experience. You have to know that everytime the team changes, your relative weights for each story will change, since they are based on a specific team's velocity. If we can't have a team dedicated 100% to the project, we don't go agile.

For each story you need to drill down a little on the major components needed. For each story you assign a weight, or points. The whole team (not only programmers) should take part doing this. For our point system we use 1, 2, 3, 5, 8. If anything falls above 8 it should be split into smaller stories. It will take 2 or 3 iterations before the team becomes confortable in estimating stories. And between every iteration, every story should be re-estimated. Don't take too much points in the first iteration, as a lot of setup occurs during that first one.

Mathieu
http://simpleadn.blogspot.com
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Our team has dropped estimating using story points. We just don't find it very effective... and instead estimate based on the largely taboo days. We allow the following scopes: 0 (why are we talking about this... just do it and be done), 1/2 day, 1 day, 2 days, 3 days, >3 days (not a specific number... just greater than 3 days). Anything greater than 3 days must be broken done into smaller stories... sometimes this will require a short spike to increase our understanding on this problem.

The problem that we have always found with story points is that it is just a relative concept based on a stick in the mud... and that stick in the mud tends to be a moving target over the course of a project.
 
kri shan
Ranch Hand
Posts: 1471
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Our team has dropped estimating using story points. We just don't find it very effective... and instead estimate based on the largely taboo days. We allow the following scopes: 0 (why are we talking about this... just do it and be done), 1/2 day, 1 day, 2 days, 3 days, >3 days (not a specific number... just greater than 3 days). Anything greater than 3 days must be broken done into smaller stories... sometimes this will require a short spike to increase our understanding on this problem.


It is not SCRUM way.(follows (Guess)timate)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic