Sunday, June 20, 2010

User Stories or Use Cases

This seems to be the question of the month. I got it quite sometime in last few weeks. So thought of penning some of the discussions, thoughts and research I did on it.


As Dr. Cockburn said it, besides the first three letters, there is nothing common between Use Cases and User Stories.


Use Cases are favorite of the technical world when it comes to capturing the functional requirements. It allows you to capture many details including the functionality, alternate flows, exception conditions, and other things associated with the requirement. And it asks for more detailed analysis and brings a more formal way of capturing the requirements. But a major draw back of Use Cases is it requires you to capture too many details right up front and calls for a good amount of documentation.


User Stories, on the other hand are a very "informal" way of capturing the requirements. It focuses more on the discussion between Developers and Users. It allows you to capture these details without any formality and with clear focus on understanding the requirement as the user will like to see it implemented. To add to the informality associated with user stories, let me mention that many teams use the Story Cards - a complete non-electronic way of capturing the user stories. The beauty of the user stories is it is depicted the way user understands it.


I remember I read it somewhere - the three "C"s of user stories - The Card, The Conversation and the Confirmation.


The CARD is the medium. It is small big enough to write a user story and small enough to keep it short that a developer can implement.


The CONVERSATION is the key aspect of a user story. The story on the card is only the notion and expects the developers that the story is not complete without a Conversation with the user. So get into discussion and get the details you want, only when you are ready to start implementing.


The CONFIRMATION is an agreement between the developer and the user on how the story will be implemented or let us say 'when is it complete'. It is the acceptance criteria or the 'definition of done' for the story on the other side of the card.


Well, the real question still remains - What shall one choose ... User Stories or the Use Cases? What is the criteria?


I think the answer lies in what you need. If your customer expects the very well defined formal documentation, guess your choice is Use Cases. But if you have an opportunity to discuss and work with customers closely and if you are not very keen on very formal documentation, well go for Use Cases. But let me tell you that Agile as such does not stop you from or even recommends against creating Use Cases.

No comments: