I found two techniques for estimating user stories:

  1. by the size of the story, which is unit-less

  2. by the time estimate, which is measured by days

The first uses relative comparison between stories to infer time, and it should be independent on developer experience, while the second depends on developer experience.

I tried the first which is good, but I believe the second is more developer-friendly, and I want to see the pros and cons of each of them from practical experience. Any idea?

closed as not constructive by Jarrod Roberson, Oded, gnat, Walter, Robert Harvey May 8 '12 at 22:32

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    could you please say why you downvote the question so that I know where is the problem? – Sameh Deabes May 8 '12 at 15:16
  • 4
    Your question is too open-ended; you're asking for a "list of things" (the pros and cons). – Robert Harvey May 8 '12 at 15:18
  • +1 as I'm interested to find out what resources you are referring to. Can you link the resources please? – CodeART May 8 '12 at 20:19
  • @RobertHarvey: I don't think the question deserve a downvote; I am asking about pros and cons of specific thing (estimation) from the practical point of view. When I asked the question I intended to mark it as wiki, but I didn't see anything for that; may be I don't have enough reputation to mark a question as wiki! If anyone can make it wiki, please do! – Sameh Deabes May 8 '12 at 22:23
  • 1
    @CodeWorks: as for the sizing technique, there is a presentation by Mike Cohn of Mountain Goat Software mountaingoatsoftware.com but I couldn't remember which one! As for the days technique, I found it in Head First Software Development amazon.com/Head-First-Software-Development-Pilone/dp/0596527357 – Sameh Deabes May 8 '12 at 22:28

If you estimate in terms of hours, and run over or under, what does that say about your other estimates? How do you then adjust the schedule? Everything has to shift, and it's ugly.

If you estimate in terms of complexity, there is no over and under. It's really just a case of saying this seems more complex than that, and about the same as the other thing. You can then build a track record on how much effort something of that relative complexity takes. This is one of the basic premises for time-boxing in Scrum.

If you are wrong about the complexity of an item, and something that seemed simple turns out to be complex, you can adjust it without serious repercussions on other estimates.


Most production projects are run based on a schedule of some sort. The PM usually needs to know when something will finish, at least approximately. If I tell you that this item has a complexity of x, the PM can't put that on a Gantt chart unless there is a way to translate complexity to time units. That is why, INMHO, using time estimates is good for planning (I assume you use estimates for that). Now choosing the unit of days is kind of debatable. You may want to see Agile Planning: ‘Ideal Day’ – User Story Estimation.

Not the answer you're looking for? Browse other questions tagged or ask your own question.