Some stories are easy to estimate and take 30 seconds to a minute to figure out. Other stories can take a few minutes if we have to discuss, in a fair amount of detail, what it will require. When you have a lot of stories to get through, this process just takes too long. I would imagine the same danger comes in with SAT graders who, after spending the whole day grading, might start to rush a little bit. Near the last few stories, the estimates begin to come off a bit faster. Given, these are just estimates and not hard contracts, it could still be a concern. It might be better to do just a few estimates at a time, or perhaps to charge a small fee to get an estimate since it takes so much time.
"90% of confusion comes from bad naming" - Eric Smith. Its funny that he said this today, because I also got a text from a previous co-worker today quoting some of my code:
be_in_the_tab = !conditional_no
Its pretty awful... I spent a few minutes myself just trying to figure out what I meant. The issue is the name 'conditional_not' which was actually a boolean meant to represent if the word "not" was in a string. This was for a cucumber step definition, which had an affirmative and negative version, so I wanted to keep the same logic but just reverse it if there was a 'not' in the acceptance test.
So true it is though. One poorly named class can drastically confound the poor soul trying to unveil the intent of a package. One inaccurately named method can hide the purpose of a class. A single thoughtlessly named variable can transform a simple method into an enigma. Just one boolean named 'conditional_not' can inspire a coworker to remind you of your ineptitude.
If you can't think of the right name for a class, method, or variable at the time you need it, then remind yourself to change it later. You don't want to be leaving behind a trail of confusion. Just as a poor name can hide the purpose or goal of some code, a good name can make it clear as day.