Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Monday, October 16, 2006

How Big Should Your User Stories Be?

How big should your user stories be?

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.

For more on agile tools and techniques:
(Tags: , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • I think you've hit the nail on the head with the statement that "story writing is best performed as a collaborative exercise". A user story is, of course, 'a promise for a conversation', but the existance of the story implies that a (shorter) conversation has already taken place.

    We try to keep our stories within the range of 1 – 3 'ideal coding days'. If they're smaller, we try to combine them with related stories. If bigger, we try to split them up. Neither of these is always possible, but it's a good target.

    By Anonymous Anonymous, at 1:42 AM  

  • Agree with above comment, which is the same on our team. Sometimes we include acceptance criteria and exclusion in our stories , especially for complicated business logic or validations, Acceptance criteria might be when I enter x and y z is x*y -5 or maybe performance related, like I want to search and get results in under 2 seconds. Exclusions might be, we assume that the assets are available, or we assume the page for the search results listing is a separate story.

    Some of this stuff can be padded out in the story, so then our story does become a working document, starting as invo to convo but ending as a record of agreed aspects/exclusions/acceptance criteria, this is useful as the business requires some audit trail to requirments more often than not, and whilst I believe in code being documentation. For other interested not technical stakeholders, reviewing the story cards with this conversation/agreed contract stuff included it can really help

    By Anonymous Anonymous, at 11:32 PM  

Post a Comment

<< Home