Slicing by Acceptance Criteria
Many User Stories contain a number of explicit or implicit Business Rules usually represented as Acceptance Criteria. If a User Story is so large or complex that we could not complete it in a single sprint we can consider slicing the User Story by its Business Rules or Acceptance Criteria.
If we use a standard ecommerce website order entry process:
As registered customer
I want to purchase the items in my shopping cart
So that my products can be delivered to an address I specify.
If we assume a standard order entry process and shopping cart, the following ‘Business Rules’ based stories would emerge:
As the site owner
I want to decline orders below 20 dollars
because order processing outweighs profits;
As the site owner
I want to decline international orders
because credit card fraud and shipping expenses make these orders unprofitable;
As the site owner
I want to decrement inventory count when payment clears
so other customers see an accurate stock count;
As the site owner
I want to automatically cancel orders for which I have not received payment within 48 hours
so I can sell them again to other customers;
In most cases the Acceptance Criteria will give you a relatively close mapping to Business Rules. Since the Acceptance Criteria are typically used as the outline for Test Scripts this method aligns well with Behavior Driven Development or Acceptance Test Driven Development. Slicing the User Story in this manner allows us to focus on the Business Rule /Acceptance Criteria that is most important to the customer first. The customer may decide that simply placing a message on the orders landing page that states “orders below 20 dollars cannot be processed” will suffice. In the first release of the product, with limited traffic, it may be ok to manual cancel orders for which payment has not been received or manually decrement inventory when product is shipped. In any event the more we slice down a User Story the more specific we can get when discussing Acceptance Criteria as well as identifying Delivery Team Tasks. At the end of the day this more granular view of the User Story allows us to make much better delivery estimates and ensure a more accurate representation of the customers wishes. However, like Database Normalization there is a happy middle ground between too coarse and too granular. So find your balance.
Previous Method 3 – Slice by Test Case ******* Next Method 5 – Data Types or Parameters
