Value..

Stories being testable and valuable is as important as them being small and independent. Perhaps more... because these are the two important characteristics which in fact drive the size of the the story.

Like we saw that an agile analyst can sometime fool himself by creating independent stories, one can also blunder quite easily when it comes to testability and value of stories. Let's look at an easy example:

Imagine a customer entity in a system with about 50 odd attributes. Creating one story capturing all these attributes will be a real mess. An analyst would (and should) readily want to break the story. What he/she might end up doing, however, is breaking the story thus...

• First story for creating the customer domain object, giving values for all the attributes (in code) and saving it to the database.
• Second story for creating the screen
• Third story for adding validations.

Task & sizewise, this will work fine. But where is the value? What are we actually delivering to the user that he/she can use?

Another problem is the testability. What an analyst should remember is that a story should be testable by the end user... not through code.

So what does one do in these kind of situations? Well, maybe (and I am quite sure) that there are different types of the customer. Breaking the stories so as to capture details for each type can be a great start. This is called a vertical split.

In situations where this is not possible the team might have to resort to internal breaking of stories. The catch is it can be shown to the customer only as a complete functionality, which lengthens the feedback cycle which defeats the whole purpose of breaking the story!!!

These are the situations to beware of... But then that's what we get paid for right??

The perfect split is somewhere out there and finding it gives an analyst immense happiness... and who could help you better at that than the client?

;-)