The BA Skill Set – Splitting User Stories
I’ve spent a lot of time working with a large number of developers over the past 3 years. Their skill sets and experience have varied greatly, but the one consistent behaviour I’ve encountered, is they all work in a logical structure.
Their focus tends to be on one working piece at a time rather than a full pass and then review.
It’s also how I have tended to approach my requirements after transitioning to agile many years ago. Although I’ll have a rough idea of the requirements at a high level, the detail comes from working on a small number of requirements at a time. This way further requirements are teased out in the details and the cycle continues.
Although I’ve picked up a great deal of experience writing requirements in different ways, it has primarily been user stories that have been the preferred requirement for development teams.
Early in my transition, I found some of my more complicated user stories tended to be too large to be delivered within a single sprint. Over time, I acquired more skills and gained more experience in breaking down larger stories into more manageable chunks.
I’m a firm believer in the Peter Drucker quote “what gets measured gets managed”. As such within such short sprint windows, it’s the user stories which are kept lightweight that offer real value to the overall delivery and allowing the team to deliver more quantifiable value.
There are many different techniques for breaking down stories out there, but the one that has resonated the most with me is Mike Cohn’s SPIDR method. It also happens to be one of the simpler methods once you understand the basic concepts.
SPIDR is an acronym for 5 techniques used for splitting user stories.
S – Spikes
P – Paths
I – Interfaces
D – Data
R – Rules
Spikes
In bucking the acronym trend, S (Spikes) is actually the technique which tends to be invoked last and least often. Similar to spikes in the agile development process, the spike occurs when a story cannot be estimated and requires a time-boxed period in which further research and understanding can be carried out.
It reasons that with this increased knowledge comes more likelihood that we will better understand the story and be able to then break it down into smaller stories.
As a BA I often feel like I’ve failed to deliver good enough developer requirements if a spike in splitting is called. That being said, I recognise how valuable they can be, especially recently when working with newer technologies the team were not already familiar with. Without a much better understanding of the story, the development team and I run the risk of delivering a substandard product.
The best developer I ever worked with used to plan out his development on paper before ever attempting to write a single line of code. In a similar vein, the spike allows the time needed to better understand and plan the customer’s requirement, and thus, we have a better chance of delivering actual value first time without the need for the dreaded re-work.
Paths
A path describes where alternate flows exist towards the same end goal. Let’s take an example from a recent project I’ve been involved with. The high-level story is that a customer needs to be able to pay for goods within a store. This story has many paths available. For example, the ability to pay with cash, credit card (both chip and pin and contactless), customer credit account and mobile payment including both apple pay and android pay.
In this case, the original story can be broken down into 6 smaller stories, each with their own specific details and individual tests.
As a BA we would have to look at the individual merits of the split, working out if 6 stories offer more value than say 4 stories where 2 of those have the same requirement covering multiple methods of pay.
We could then estimate each story and rather than doing all in one sprint, we could do just the most valuable for now and work on other later into the project.
Each path allows us to specify each path in its own story, then re-group certain paths if they offer no additional value being treated as individual stories.
Interfaces
Interfaces refer to the amount of detail across, or from differing channels. Let’s take another example from one of my recent projects. Once complete, this project will offer the customer the ability to order across multiple channels including the website and mobile site (optimised for phone and tablet), but for the initial phase, we have chosen to offer the service only via the website. While mobile customers are an important subset of customers, the biggest value is getting the project out there, getting customer feedback, and measuring initial performance so we can better serve the customer. Mobile will follow, and when it does, it will likely be an even better and more polished customer offering based on the fact we have split the initial story into individual channels.
Splitting stories down based on interfaces offers an increased amount of flexibility and the ability to more accurately estimate the development and testing time required for each interface.
Data
Let’s say for example we are rewriting our website. We have a number of large stories related to the content we are going to display on the landing pages of the website. We know that based on the time of year women’s clothing is traditional much more likely to be the biggest seller over menswear and home furnishings. We would, therefore, write stories targeted at getting these types of products displayed prominently. For now, we focus only on womenswear as that’s where the most value lies at this time of the year. Later on, we will do the same for homewares, then after that menswear.
We split our stories based on the most valuable data and that offers the best return on the time invested for the customer/business. Splitting stories based on data gives a greater degree of flexibility.
Rules
Business, regulatory, technology rules etc…. all offer the potential for splitting stories.
Let’s take the example of a customer of a clothing retailer with a credit account. The company ran a credit check on the customer at the time they opening the account. Based on their credit score the retailer internally sets different credit limits to reduce the risk of customers defaulting on repayments, and to be more ethical by helping to reduce the customers’ ability to overextend their credit to the point they cannot afford the repayments.
The business rules in this case state that a customer cannot purchase goods on their credit account for a value higher than the company defined credit limit.
To split the story this rule could be omitted and the developer’s first iteration allow purchases up to the top value of the largest credit account. The additional rules with much more complex logic will be delivered in a later iteration, but to test the functionality of a credit account purchase, rolling out without the self-imposed business rules allow the business to test the rest of the functionality much quicker.
Splitting the story based on the inclusion/exclusion of rules allows quicker delivery and testing. The value of the rules can then be realised in a later iteration by changing the now working version.
Success and Story Sizes
I’m a firm believer that ideally the largest sized story allows an individual developer to deliver within a few days. Based on that principle, over the course of a sprint, the number of stories that can be delivered allows the project manager/product owner the ability to forecast realistic delivery dates and better plan releases.
As a business analyst, it is imperative that I give the developers the best chance of accurately estimating stories within sprint planning and delivering a good number of them each sprint. My end goal is to put a working version of the required functionality in front of the customer, as early and often as possible. The success of this relies heavily on the size of the stories in the backlog.