• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh

howto estimate story effort

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?


 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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)
 
I can't renounce my name. It's on all my stationery! And hinted in this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic