Splitting CRUD stories

Two of my colleagues came across a CRUD (Create / Read / Update / Delete) story, and asked me for advice on how to convince people on splitting stories.

I typically prefer to have smaller stories. In this case, instead of having one CRUD story, I would have one for Read, another for Create/Update and a story for Delete.

Here is an example.

As a online store owner, I want to Create / Read / Update / Delete products so that I can offer my customers the top rated products

Instead of having this CRUD story, I split it like this (I will add a few sample tasks for making it more illustrative):

As a online store owner, I want to Read (view) my products so that I can review what is current available on my site

Sample tasks:

• Create DB table
• Populate table with a few sample data
• Create select DB script
• Create for viewing my products
• Create automated functional tests for viewing functionality

As a online store owner, I want to Create / Update a product so that I can offer my customers the top rated products

Sample tasks:

• Create insert / update DB script
• Create UI for create / update a product
• Create automated functional tests for adding product functionality
• Create automated functional tests for updating product functionality

As a online store owner, I want to Delete a product so that I can offer my customers the top rated products

Sample tasks:

Create DB table for deleted products

• Create delete DB operation
• Create UI for deleting a product
• Create automated functional tests for the delete functionality

This sample is very specific for CRUD stories. There are other ways for splitting stories.

Mike Cohn's book, User Stories Applied is a must read on this subject.

Splitting (or deciding the size of a story) is controversial. Mike Cohn have popularized the INVEST acronym: Independent. Negotiable. Valuable. Estimatable. Sized appropriately. Testable

agree with the S in the acronym listed above: Sized appropriately.

But when I first read the INVEST acronym, the S was for small. I know Sized appropriately is not very specific, but it is more realistic. It is not about being small; it is about being sized appropriately. For this consider several reasoning on splitting your stories. The links below have more on this subject:

http://lassekoskela.com/thoughts/7/ways-to-split-user-stories/

http://agilecoach.typepad.com/agile-coaching/2010/09/ideas-for-slicing-user-stories.html

http://xp123.com/xplor/xp0512/index.shtml