One wheel or two, there will be a data variation.

One wheel or two, there will be a data variation.

User stories represent a change in approach from capturing and documenting requirements at the beginning of the project in a classic requirement document. Those requirements whether written in prose style or in use cases are then put under close control using techniques like change control boards.  In Agile techniques like user stories are used to capture user intent knowing that in order to deliver functionality conversation and feedback will be required. Every story is different and will require more or less work to express.  Perhaps to abuse the metaphor of a story, consider the production of a novel, in general the longer the novel the more effort that will be required to write it and the longer the author will have to wait for feedback. Shorter stories can generally be delivered faster, meaning that you can get feedback faster.  This one of the reasons we split user stories.  

There are many patterns to help teams split stories into more granular increments, that are also complete deliverables, and meet the INVEST criteria. Data variations is one such pattern.  Data variations occur when there are nuances in the groups of data needed to describe an object or an entity (for example, retail customers and wholesale customers are similar, but probably have some data differences).  The differences between the different kinds of customers represent an opportunity for splitting the stories that impact customers.

We going to build on the time accounting example from earlier this week. We noted that a contract employee could not approve a time sheet, while certain types of employees could approve time sheets.  This business rule could lead to a difference in data structure for contract employees vis-à-vis regular employees (note: this is not to suggest that there might not be other differences in the data structure).  Based on the data structure difference the user story, “As a business owner, I want time entered to be approved by an employee to avoid the perception of conflict of interest” could be split based data structure variations as follows:

As a business owner, I do not want contract employees to be able to approve time sheets to avoid conflict of interest.

As a business owner, I want time sheets to be approved to ensure proper billing.  

A less nuanced example of data variation is an extended family.  A simple entity relationship diagram (ERD) of a family suggests several different groups of data.


If we were writing stories based on variations in data, using the model (above) we would expect stories related to individuals, roles, relationships and family. 

Many data variations are driven either by workflow or business rules, therefore splitting by data variations can be feel very similar to splitting other techniques.  Using data variances to suggest how to split user stories provides Agile teams with another tool to groom user stories. Having a pallet of different techniques will help a team stay effective regardless of project type or business situation.