Whenever I hear the word "agile" I reach for my revolver.

A huge pile of chest-thumping and vapid articles about benefits - and a lot less about pitfalls. Often, people just say "uhm, you know, it's not a silver bullet" and "just don't change the process" and then you have to glean the rest yourself.

So google for pitfalls of agile and read over, learn the salutary science of Agileology, and this post will be sitting here until you're done.

Ok, I see you're back. Impressed? However, most of the articles, while often interesting and correct^[1],

• are either too abstract
• or concentrate on the already mentioned dont-change-the-process things: you must have unit tests and you must do daily standups, etc.
  

All true, but what about those who implement the process correctly? Don't they face issues as well? Couldn't there be pitfalls in implementing the parts?

Story points. 

In agile software development, you typically estimate requirements in story points rather than in man-days. Points allow you to embrace ambiguity in requirements and, generally, planning is easier with them: you know how many points per sprint you usually do, and thus have a (rough) answer to the notorious "how long will it take" question.

Other benefits are also quite obvious:

• Points are easier to agree on. They are simple: relative size of a task in comparison to other tasks. Some teams even use exponential (1,2,4,8,..) or Fibonacci (1,2,3,5..) scale for that. If your etalon task is 3 points and the task you're estimating looks bigger, you cannot say "it's a 4 pointer". It should be either 5 or 8 or 13, etc - to cover possible risks.
• Estimations in points tend to be more realistic. We, developers, are naturally optimistic and estimating in a group is an eye opener. Also, for a customer/manager, it is easier to persuade an isolated Robinson Crusoe developer to put the "right" estimation, rather than to win over the whole team.

Issues you can prevent.

Points indulge fire-and-forget thinking. While discussing the estimations, you come up with certain ideas on why this story is bigger than that one, etc. This, often invaluable, knowledge will be thrown away unless someone records it for the next iterations. While agile methodologies belittle the need for documentation, this one can save you some time and make future estimations  more consistent.

There is a temptation to divide the number of accepted story points by the number of developers to see the average contribution. While this can be a good metric, betting on an individual developer diminishes the role of the team - and the idea of a self managing team is a central one in agile development. It is the responsibility of the team to get the stuff done, and people organize in a way how to do it better and faster, helping each other rather than making Stakhanov runs in individual productivity.

Collaborative estimation could steal quite a bit of time in talky discussions. The easiest way to address that is to estimate by playing planning pocker^[2], where developers reveal their estimations all at once, and only those with the biggest and the lowest estimation participate in the conversation.

It is difficult to estimate bugfixing within story points. Bugs take time to fix and test them, so if you want careful planning, you need to account for them. However^[3], time spent on bugs should not add up to the team velocity, because otherwise you credit the team for buggy code!

Anything else?

Is there anything else I've missed? Any issues you have faced with story point estimation? 

1. Here's my favorite article on risks of agile.
   
2. Check out planningpocker.com, a free tool for estimation and planning. A great resource, esspecially for distributed teams.
3. Jack Milunsky has a nice write-up on accounting for bugs with a really interesting conversation in comments.