I’ve had 3-4 different conversations this week on the proper size of a user story.  My opinion is to simply slice your user stories into the smallest chunks of work that are still:

A.)  Testable

B.)   Provide some sort of real business value

By testable I mean that there is something that a tester could actually test.  As an example, think about a typical dynamic website application that displays a status report of some kind.  You can’t really write a user story for “fetch data” without the data display because it provides no business value.  You could, however, divide the reporting screen into smaller user stories like:

1. Query by state
2. Query by zipcode
3. Sort the results
4. Export the results to Excel (I’ve lost track of the number of times and programming languages I’ve done this with now)
5. Persist query settings

I think smaller user stories help dramatically in creating a smooth running Agile team.  The smaller (and more detailed) the user story, the more accurate the developer estimates will be.  Management types will be happier because they love the predictability of accurate estimating.  The development team can demonstrate progress more often, and it’s just plain cool to see the story cards moving on the story wall.

A highly desirable ability of any team doing iterative development is the ability to produce production ready code at the end of each iteration.   Another related goal is to never carry a nontrivial defect across iteration boundaries.  The only possible way you can arrive at production ready code at the end of the iteration is to get the testers something to test as early as possible in the iteration.  Something I learned the hard way is that you cannot dump the full iteration’s code onto the testers on the last day of the iteration.  If you can break your user stories into smaller units of work you’ll be able to smooth out the workload of the testers more evenly across the duration of the iteration.  A useful thing to watch is the number of stories that are done (coded, tested, and customer approved) at the midpoint of the iteration.  Ideally you want to be halfway done with the iteration stories spread smoothly between the actively coding, testing, and done columns.

One of the major advantages of Agile development in my mind is the way that the workload is more evenly spread out in a sustainable pace.  We don't have much in the way of crunch time, but we also rarely have any downtime.  When I worked in a waterfall shop I remember being constantly frustrated at the cycling between being overworked at the end of a project and underutilized and bored between development cycles.

My team isn’t at this point yet, but we made some very significant changes this past week (plus finally added an onsite tester) that I think will help us get there.  More on that later...