Dave Churchville has posted a blog entry on how big he thinks user stories should be: "small enough that the team and the customer can see and feel the forward momentum." According to Churchville, smaller stories create positive energy and keep everyone engaged in the project. But if customers are supposed to be writing the stories, how can they be trained to control the size when they can't estimate the effort? Churchville's solution: a collaborative effort. His staged interaction between a customer and developer illustrates the point that developers have to be savvy enough to break out stories that have value but are small enough to be manageable. One drawback to smaller user stories that Churchville does raise is that it may be difficult for a customer to prioritize a large number of stories effectively. In this case, Churchville recommends that the customer prioritize sets of small stories grouped together according to theme. When it comes to user stories, what size works best for you?
- Posted by: Regina Lynch
- Posted on: October 17 2006 14:51 EDT
- Introduce the Idea of "Developer" Cards by Damien Bastin on October 17 2006 19:08 EDT
- Re: Dave Churchville: How Big Should Your User Stories Be? by Jin Chun on October 18 2006 04:46 EDT
This is something that we talk about all the time on our project. When a piece of functionality (lets say something like "Do Foo") is identified by our customer/user, they will turn it into a brief small descriptive story of around 2 paragraphs max. Then at least 2 developers (pairing is good) will sit with the customer/user and look at the "Do Foo" story card and ensure that it has an "end-point". Having an end-point means that "Do Foo" is something that can be verified with an automated acceptance test (junit with some extra java fixtures, in our case), and that it is a piece of work that the customer can see and verify. Then the developers will estimate the work required. If this initial estimate is greater than 3 days (a magic number for our project) for a pair, we need to break it into smaller pieces. We make story cards like "Do Foo - Part A - Put Foos in the Database", "Do Foo - Part B - Retrieve and Polish Foos", "Do Foo - Part C - Present Foos on a Shiny Plate". We call these "Developer" cards. They are really, really brief, normally only a title and one paragraph max. Each of these individual parts of "Do Foo" dont mean much to our non-technical customer, but importantly, each part takes less than 3 days for a pair. We make an automated test for each part and get to feel some forward momentum within the development team. Chances are, we will be asking the customer/user questions about certain aspects of "Do Foo", so they get a feeling about how the story card is going as well. At the end of the parts of "Do Foo", we take a step back and ensure that we have reached the end-point that was described in the original story card, and then invite the customer/user to sign the "Do Foo" story card off.
nothing new, meaning this same problems happens whether you use user stories, features in fdd, use cases, whatever, there will always imo be a need to have the developers facilitate the "partitioning" of the problems into the right chunks. Prioritization imo is mainly an exercise in taxonomy (as in fdd) but in any case, strong collaboration with the customer/user will always make life easier. Scrum is pretty good at facilitating prioritization in the backlog, as long as everyone agrees on the labels (ie it facilitates communication and not the ego of the person writing the stories) then it becomes manageable as well.