Small Stories, Large Stories

One question that keeps analysts busy for a most of the time is whether or not to split a story. Here's my philosophy behind my unending support for small stories.

Let's start with one huge story that covers everything that is required to be done in a project. It is estimated by the developers at say 120 complexity points which converts to about 300 days. Following are the consequences.

• A requirements document (the story) - coupled with the time taken to prepare such a document
  
• The techinical discussions and decisions for implementing these and of course the time required
• The implementation of this story
• The testing and
  
• The user acceptance (well usually non-acceptance and it takes very less time too :p )

This is what we do in a waterfall approach towards software development. We are looking a 300 days feedback loop because that's when the customer will actually see the application.

Agile works towards shortening each of these phases and doing them over and over again until all the requirements are fulfilled. Thus everything boils down to the feedback cycle you are looking at. Let's look at a shorter feedback cycle, say 100 days. Thus you end up with 3 stories with an estimate of 40 complexity points converting to 100 days. Which means you get feedback thrice during the project because the customer reviews the functionality delivered by each 100 day story as soon as it is completed. That's somewhat better.

Let's just try and make this a 10 day feedback cycle. We thus have 30 storys with an estimate of 4 complexity points converting to 10 days. What we are looking at is basically a 2 week iteration. Now that's really good. I'd however go for one more split so my stories have a complexity point estimate of not more than 2.

The upside
The upside other than what we established above is that developer estimates are generally exponential (although they are supposed to be linear). Which means that one 4-point is not equal to four 1-point stories. It is exponentially bigger. Thus the smaller stories you have the lesser will be the actual time taken to implement, test, get feedback, make necessary changes and deliver.

The downside
Well, there is no downside. The only thing required is constant interaction with the customer for analysis of new stories and review of completed stories.

Todo
An agile team should set customer expectations appropriately before starting the project. The customer participation is the heart of the project. Successfully establishing a short, reponsive feedback loop is the first and foremost thing to do when doing an agile project... and the stories, keep them short.

Small is beautiful...