Splitting User Stories

I've heard many times from my teams that they have a hard time estimating user stories that are moved from the backlog to the Sprint, the most commonly sited problems are related to the size and ambiguity of user stories. I believe that this happens partly because the confusion about the backlog, more precisely, teams tend to think that there's only one backlog.

It's crucial that Scrum teams to recognize that in fact there are two backlogs, one Product Backlog and one Sprint Backlog. I describe below some characteristics of both:

1. The Product Backlog contains high level user stories created mainly by the Product Owner. Those user stories has to have business value and usually will require a lot of man-hours to implement.
2. User Stories in the Product Backlog has to be prioritized by the Product Owner based on her perception of business. Of course teams can have an stake on this but business value should be the key driver.
3. During the planing stage, teams take user stories from the top of the Product Backlog, digest them and decide what to include in the Sprint Backlog. Teams are expected to split Backlog User Stories in smaller chunks if necessary. Actually, it's highly recommended that they do so. Note that Product Backlog User Stories are high level whereas Sprint Backlog User Stories has to be good instruments for estimation, planning, and tracking. The 'devide and conquer' principle is applicable here.
4. Even before deciding what to move to the Sprint Backlog, teams need to considered their velocity (measured in story points or hours) to have a feel of their capacity. Velocity is a great indicator that helps preventing teams for overcommitting, of course that for this to be effective, teams need to have a clear perception of their velocity.
5. A crucial point here is that teams and not Product Owners decide what to move to the Sprint Backlog. Of course that the PO can influence and negotiate, but she shouldn't be allowed to overload teams beyond their capacity. Successful teams don't refuse to work on something, they accept to work on that something in exchange of something else.
6. A symptom-at least in early Sprints-for things not going that well is that the Sprint Backlog would be bigger than the Product Backlog, this might indicate that: A, the Product Backlog doesn't exist or still in process of being created or B, the team is overcommitting and trying to complete too many User Stories in an Sprint. A could be a also a indicator that the PO is not involved in the project. B typically happens when teams aren't aware of their own velocity.

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.