Ricardo Mestre’s Blog

Here is a very interesting article about velocity signatures of agile Teams (thx, Dan)

As promised to Cairo, here are the criteria I recommend for a Team to split user stories. Please take into account that none of this was invented by me: I’ve been following the criteria mentioned by Mike Cohn in his great book “Agile Estimating and Planning” - which is a must-have for anyone using Scrum.
So, after the proper attribution, here go the criteria:

When to split:

• A user story must be split when it is too large to fit within a single iteration. And why is that? Because it makes no sense that the Team commits (during the sprint planning) to a user story that it knows, beforehand, it will impossible to finish (according to the Team’s definition of “done”) during the sprint duration. That would be commiting to do the impossible, which must be avoided.

• When a user story is small enough to fit within a sprint, but it won’t fit within the sprint being planned because there isn’t room left. Again, this must be done in order to prevent over-commitment.

• It can be useful to split a large user stroy (an “epic”), if a more accurate estimate is needed. Why? Because we, humans, are much better estimators when we are estimating within the same order of magnitude.

How to split:

• Split a large user story along the boundaries of the data supported by the story. For example, the user story “As a user, I want to be able to enter my personal information” would be splittable into several small user stories, like “As a user, I want to be able to insert my name” and “As a user, I want to be able to insert my birthday” and “As a user, I want to be able to insert my phone number”

• Split a large user story based on the operations that are performed within the story. A good way to do this is split the story along the proverbial CRUD (Create, Read, Update, Delete) operations.

• Remove cross-cutting concerns (such a security, logging, error handling, etc.) and creating two versions of the story: one with and one without support for those cross-cutting concerns.

• Split a large user story by separating the functional and nonfunctional aspects into separate small user stories.

• Split a large user story in small stories, if those small user stories have mixed business priorities.

Hope it helps. Oh, and go get the book: it’s that good!