Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 0 down vote favorite

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?

share|improve this question
3  
could you please say why you downvote the question so that I know where is the problem? – Sameh Serag 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? – CodeWorks 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 Serag 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 Serag May 8 '12 at 22:28
show 1 more comment

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 specific 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, see the FAQ for guidance.

2 Answers

up vote 2 down vote

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.

share|improve this answer
up vote 1 down vote

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.

share|improve this answer

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