This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: How Big Should Your User Stories Be?
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
Although the answer should be "it depends", I'm going to be a bit more opinionated than that.
User stories should be small enough that the team and the customer can see and feel the forward momentum. This creates tremendous positive energy and keeps everyone engaged in the project.
So if the team is just a couple of developers, the story size is probably best measured in hours or a couple of days of effort at most. For a two-week iteration, you might then have 8 or 10 stories.
When the team size is larger, you might lean towards the larger end of the story size scale with measurements in days, but less than a week of effort. In my experience, estimates that are beyond about a week of ideal effort are often substantially less accurate.
But who gets to control this story size? Aren't customers supposed to be writing storeis? How can they be trained to control the size when they don't have the ability to estimate the effort?
In reality, story writing is best performed as a collaborative exercise. A typical interaction might look like this:
Customer: "I'd like our movie website to have a new user reviews feature"
Developer: "Great, let's talk about what you'd like the users to be able to do"
Customer: "For starters, when they view a movie listing, there should be a rating thingy that shows how many stars other viewers think it deserves. And you should be able to see other user comments. But we can't have any profanity on the site!"
Developer: "Ok, so you'd need a way to add ratings, and a way to show them to the users, ability to add and show comments, and a profanity filter. Why don't we split those into four separate items, and you can tell me which one you want first?"
Customer: "Well, we could start with just the ratings for now, then we wouldn't need to worry about profanity."
Developer: "OK, great, we'll estimate what it would take to add ratings, and to show them for each movie".
The developer here has to be sufficiently savvy to try to break out stories that have value, but are small enough to be managable. This isn't always possible, but on average you'll wind up with bite-size chunks instead of a Biggie-Sized story.
One caveat with smaller stories is that if you wind up with a great deal of them, it can be difficult for your customer to prioritize them effectively (it's tough to rank more than about 10 things). You may wind up with categories or "themes" that group together a set of small stories. The customer can then prioritize around themes like "Security", "User Reviews", or "Reporting" first, then later determine which smaller items are most important.
Let me know what size stories you use, and how it's working out for you.
Previous Topic
