User Stories Size, Having a Problem Estimating Them?

Estimating user stories size can become a dangerous obsession, I mean, what are the changes that you can accurately estimate the size of a piece of work in a changeable and fuzzy domain like software development? The more experience that you acquire on this, the more that you'd tend to answer that chances are very slim. And why is that? Part of this is because you don't have fixed requirements, actually you don't want to have fixed requirements, we're doing Agile remember?

But then, how can you provide estimates to keep your bosses happy? You might try to provide extra-super-pessimistic estimations to create some buffering in case things get ugly, but this might create the false perception in management that you are inefficient or at least lazy-not a bad estimator which in reality you maybe are.

So, the advice that I can provide is first start evaluating your user stories to order them from ultra-complex to piece of cake. Knowing that something would be twice as complex as something else will provide you visibility on what should be tackled first or by whom in the team. Once you have your user stories ordered, you can add a countable unit (like story points, complexity level, effort or whatever that you consider appropriate) to your user stories. By doing this, management would perceive the complexity (and hopefully the cost) of implementing something and would be able to pick what should be implemented first or what is more crucial.

Shifting management's focus from accuracy in estimations to complexity could give you some degrees to maneuver. At least you won't have to worry because you offset the mark for X number of hours. You'd be worried instead for keeping complexity under an manageable level.