How big is a User Story?

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…

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jeremy D. Miller

    J,

    I’m the worst possible person to ask about that. My preference is to have everybody but me putting information on the Wiki;)

  • J

    Hey Jeremy,
    On the topic of ‘documentation’, I would greatly appreciate reading an entry on your experience, thoughts and evolution (from a waterfall shop to current TDD) of documentation in the software creation process.

    We are an evolving waterfall->TDD house and the amount of documentation creation is a velocity killer!!!

  • http://achiveddeveloper.blogspot.com Gary Williams

    One issue that I struggle with is when you are doing ‘engine work’ — that is, creating an engine that is deep in the bowels of a system without a visible interface that a tester can see. Would you suggest an artificial UI to surface this to the QA? Fitnesse springs to mind for some reason…:-) One story per chunk of Fitnesse?

  • Jeremy D. Miller

    Chris,

    I agree with you completely. We’ve struggled a little bit with large amorphous user stories that get dropped into the iteration without enough details. I just want to get us to being able to completely finish stories within iterations.

  • chrispix

    I think it depends a lot on your particular agile process and culture. I worked in a semi-XP shop where we did 3-week iterations. For us, the main goal in defining stories was having stories small enough that they wouldn’t be split, but big enough that we didn’t have too much to track. We found that stories that would take 2 days to a week to implement were in that sweet spot.

    On the other hand, I’ve seen a scrum team with lighter tracking requirements that operated more efficiently with very small (<1 day) stories like you describe.

  • http://elegantcode.com David Starr

    Here, here.

    Very well said.