Right Sized Stories

Story size should be based on what you need now. Stories in the current iteration should be small enough that you can commit to them and finish them throughout the iteration. No larger than half the iteration. I'd lean to more like 1-3 days. Large stories put the iteration at risk. Small stories help you establish flow / quick feedback as you get things done.

Stories in the release should be small enough that you can size them. Typically no bigger than you can finish in an iteration or two. Larger than that and your sizing will likely be pretty inaccurate (i.e., when you later split the stories to pull them into the iteration, you'll likely see quite an increase in the number of points).

Stories beyond the release can be pretty large. They should be small enough that they capture the idea. Don't go too deep here. If you aren't likely to do it, don't add it to the backlog. If it isn't going to happen for more than two or three releases (if you release more frequently or have a long planning horizon, this could be more), don't add it to the backlog. If it is important, it will come up again.

Making stories too small too early increases the cost of managing your backlog. Instead allow them to remain big until you need them to be smaller and then split the story into multiple smaller stories.

Lots of blog entries have been written about splitting stories (see http://xp123.com/articles/twenty-ways-to-split-stories/ for some great suggestions by Bill Wake). The important thing is that each new story should be a vertical slice (i.e., end to end) that shows incremental value to the business (be it in allowing users to do new things or just to get feedback on the direction that you're going). Each story should leave you in a releasable state. This gives you options. You can decide whether to go further with that line of thinking or to abandon it.

When you split a story, you should size each of the new stories. The points for the new stories might not add up to the points for the old story. That's OK. You now know more about the stories. You might have added or taken away scope. Size estimates should reflect what you know now. After all, the point is to be able to use them to project what you can commit to / how quickly you will move through the backlog. Why stick with how you used to think about it?

When splitting a story, you should also prioritize each of the new stories separately. Some will be higher in priority; others lower. Don't assume that all stories resulting from the split are at the same priority as the original.

Lastly, what should you do with the original story? That depends. Unless there's a compelling reason to do so, I'd delete it. The new stories replace the old story. This makes it much easier to maintain your backlog. It also makes it clear that the new stories are independent.

What's a compelling reason? Maybe you need to tie it back to a single user deliverable. In this case, the original story (the user deliverable) is an epic / parent story and the new stories are children. I would only associate a new story with the original if it is absolutely required in order to achieve the original story. If optional, the new story would be free standing.