|
|
Breaking down by acceptance criteria: business rules
PBI’s often involve a number of explicit or implicit business rules. Take the PBI for the order process of a regular webshop:
As customer I can purchase the goods in my shopping basket, so that I can receive my products at home
Given a fairly standard order procedure, we could identify the following ‘business rules’:
- As shop owner I can decline orders below 10 dollars, because they aren’t profitable;
- As shop owner I can decline customers from outside the US, because the shipping expenses make these orders unprofitable;
- As shop owner I can reserve ordered products from stock for 48 hours, so other customers see a realistic stock;
- As shop owner I can automatically cancel orders for which I have not received payment within 48 hours, so I can sell them again to other customers;
Business rules are often implicit, so it will take some skill and analytical prowess to unearth them. How is the functionality going to be tested? Often, test cases imply important business rules. Once the business rules have been identified, it will again have improved our understanding and ability to estimate. The product owner may decide that some business rules are not important for now, or can be implemented in a simplified form. Perhaps it’s ok for now to manually return unpaid products to stock when a payment has not been received within 48 hours, or orders can be cancelled manually. Even more pragmatically, a message on the site explaining that ‘orders are not shipped outside the US’ or that ‘the minimum order price has to be at least 10 dollars’ may be sufficient for now. It will save time and money required to enforce this business rule.
|
|
|
|
|
Breaking down by functionalities: vague terms
Often we notice that user stories contain terms that are somewhat vague. That’s ok, user stories are supposed to be “Negotiable” (see Bill Wake’s INVEST acronym). Those vague terms often lead to possible vertical slices.
Example Story: As a frequent traveler, I want the weather application to store several days of weather data and display it while offline, so that I can see the forecast at my destination city when I don’t have cell service.
As a former tester, my first reaction to this story is “what do you mean by “several”? It’s a vague term. So is “display” – how will I know that I am using stored data vs. current data, etc.?. Both of these terms provide opportunities to slice by using an incremental approach. For example we might get the following slices from getting very specific about the display part:
- Create a new UI element that displays a timestamp for the last known weather data snapshot (don’t need to actually have an offline mode yet).
- When the phone has no service, add “Currently Offline” to the UI element.
- Maintain the forecast data for the last known weather while offline.
For “several days” we might get something like:
- Store the next day’s weather data
- Store five day’s weather data
|
|
Breaking down by functionalities: operations
PBI’s often involves a number of default operations, such as Create, Read, Update or Deleted (commonly abbreviated as CRUD). CRUD operations are very prevalent when functionality involves the management of entities, such as products, users or orders:
As shop owner I can manage products in my webshop, so I can update price and product information if it is changed
By identifying the individual operations required for this functionality, we can derive the following smaller bits of functionality:
- As shop owner I can add new products, so customers can purchase them;
- As shop owner I can update existing products, so I can adjust for changes in pricing or product information;
- As shop owner I can delete products, so I can remove products that I no longer stock;
- As shop owner I can hide products, so they cannot be sold for the time being;
When presented with this strategy, many teams wonder if the smaller items actually deliver business value. After all, what’s the point of only creating entities when you cannot update or delete them afterwards? But perhaps the Product Owner has such a limited number of products, that editing or deleting can be done in the database directly. Sometimes, an operation can be easily implemented in a simplified form. Deleting a product can be done in two ways; you can completely drop the record and all associated records, or you can ‘soft delete’ a product. In that case, the product is still in the database, but it is marked as ‘deleted’. Sometimes one of these approaches is easier to implement, and can be ‘good enough’ for now.
|
|
Breaking down by functionalities: conjunctions
Conjunctions are words that are connectors: AND, OR, WHEN, IF, for example, and when they’re present in a user story, they are often pretty obvious opportunities to create a vertical slice.
Example Story: “As a return user, I enter the option to save a credit card number and select it for future purposes, so that I don’t have to type in all of the data each time.”
Notice that the “I want” statement of this user story has two parts: save the number AND select it for future purposes. These are really easy to split into two slices:
- Save a credit card number to my profile
- Offer the option of using a saved credit card number on a purchase
|
|