Layered Cake

Slicing User Stories Method 6

Slicing by CRUD or ISUD (AKA Slicing by Operations)

Any User Stories involving a managed entity, such as a Customer, Order, Employee or Product, will almost always require some level of management functionality.  This management functionality will provide the ability to perform a number of operations including at a minimum operation, such as Create, Read, Update or Deleted.  These operations are commonly referred to as CRUD but that is such an unfortunate acronym as it sounds like something you get between your toes…  Not to mention the fact that in most Relational Database systems such as MySQL and Microsoft SQL Server the operations are actually called Insert, Select, Update and Delete making the acronym ISUDISUD sounds better, soapy and clean to wash away the CRUD between your toes.  So forever more on this site CRUD operations will be referred to as ISUD operations!
ISUD operations are very prevalent when functionality involves the management of entities, such as products, users or orders:
As a Specialty Kite Maker
      I want to manage Kites in my ecommerce website
So I can update Kite details and pricing info if it is changed

If we consider the ISUD typically associated with Product management, we can derive the following more specific and granular User Stories:

As a Specialty Kite Maker
I want to add new Kites to my product list
So customers can purchase them;


As a Customer

     I want to view a list of Kites available for purchase
     So that I can buy one;

As a Specialty Kite Maker

     I want to list the Kites in my product list
     So I know what Kites are currently in stock;

As a Specialty Kite Maker

     I want to update existing Kites in my product list
     So I can adjust for changes in Kite details and pricing info;

As a Specialty Kite Maker

     I want to delete Kites from my product list
     So I can remove Kites that I no longer sell;

As a Specialty Kite Maker

     I want to hide Kites in my product list
     So they cannot be purchased for the time being;

When discussing this method, the question often becomes, “do these more granular User Stories actually provide business value?”.  Is our solution really useful if we cannot update or delete products from the system?  If we consider that in the current scenario we are dealing with a “Specialty Kite Maker” odds are there are a limited number of Kites and Kite Accessories that will be in the product list.  If this is the case then adding, editing or deleting the Kites could be done manually through a database management tool like SQL Server Management Studio for the first few Sprints.  So, for the first Sprint we may just add the list (Select) functionality to support customer purchases and delay the other Update, Delete and Insert User Stories for a later Sprint.  This way we get business value sooner by minimizing “Work In Progress” (WIP) we are able to increase delivery date confidence and deploy only features necessary to deliver value to the customer.  In this scenario, the lack of Insert, Update and Delete functionality will not be noticed by the customer because these are admin only features therefore we deliver just the customer facing User Stories.  This allows us to get to market faster and begin collecting customer feedback while we work to complete additional features.  In the case of discontinued or deleted Kites it may be easier to simply add a checkbox that allows the Kite Maker to mark an item as discontinued or deleted.  This approach may keep the record in the database but simply hide it from the customer view making it easier to implement than an actual Delete operation that may require additional operations to enforce referential integrity.
In short if we break the User Story down by operation we can implement only those operations that provide immediate business value in early Sprints and add other more specific stories once the base functionality is deployed to customers and providing them with “Value”.  “Customer Value” = “Business Value” which of course in almost every case translates to “Business Revenue” to pay for all of the Solution Development.
Slicing User Stories – Method 5 ***** Slicing User Stories – Method 7

2 thoughts on “Slicing User Stories Method 6”

  1. Pingback: Slicing User Stories 7 Methods – ProDataMan Blog

  2. Pingback: Slicing User Stories Method 7 – ProDataMan Blog

Leave a Comment

Your email address will not be published. Required fields are marked *

Shopping Cart