Helpful Tips for Splitting User Stories

Splitting user stories require creativity and the right tools.

Being a product owner is hard work.  It is days filled with meetings and writing user stories.  You are under pressure to deliver working software, and if it all goes wrong, your career is often at risk.  One of the hardest parts about product ownership is a collaboration with the development team and estimation.  Software developers are notoriously hard to work with, and estimating software development is exponentially more difficult.   The estimation process is fraught with conflict and compromise.  Often, work is too large to be completed in the time box of a sprint.  The product owner in this situation should split user stories.  Today, I want to share a common technique to divide user stories.

I have a relatively straight forward process for writing user stories.  Once you write a story, the development team should try to estimate the story.  A story point estimate is a function of complexity, risk, uncertainty, and effort.  According to Kedar’s constant, the larger a story is in points, the riskier it is to complete in a sprint.  It means a set of four three-point stories are less risky to complete than a single 13-point story.  When you have essential stories with high point values, it is up to the development team and scrum master to request the story get split before sprint planning.   The product owner is often frustrated by this request. Breaking stories is additional work, and it implies the original story was too big.  I empathize with this kind of frustration.  Being asked to split a story is the team being conscientious.  It is also an opportunity to make the sprint more successful.

Richard Lawerence has written a fantastic post on how to split user stories.  I recommend you read it here.  For me, the most critical pattern is to break down work based on complexity.  Something complex is often the assemblage of smaller, more straightforward elements.  Suppose you are a sales manager for a cable T.V. station, the base rate for a 30-second commercial is $150 per broadcast so when a client purchases ten impressions they are invoiced $1,500 when the last commercial airs.  If you are going to write a user story with acceptance criteria, it will look something like this:

As a sales manager, I want to charge $150 per impression for a 30-second commercial because I want to generate revenue.

GIVEN I am a customer.

WHEN I purchase a 30-second commercial.

THEN I invoice $150 times the number of commercials purchased.

The rule is simple, and the team says following SOLID principles and authoring unit tests it would be two points worth of work.

The world of broadcast is time-sensitive, so commercials air during prime time between 6:30 PM and 10:00 PM are more valuable while ads aired after midnight are less costly.  The product owner realized this and added two more acceptance criteria to the story.

GIVEN I am a customer.

WHEN I purchase a 30-second commercial.

AND the commercial airs during prime time between 6:30 PM and 10:00 PM

THEN I invoice the customer $150 times the number of commercials
purchased plus a 40% premium fee



GIVEN I am a customer

WHEN I buy a 30 second commercial

AND the commercial airs during late night (between midnight and 5:30 AM)

THEN I invoice the customer $150 times the number of commercials 
purchased with a discount of 20%

During sprint planning, the team looks at the revised user story with the additional acceptance criteria, and they adjust the story points to eight because the story has become more complex.  A good rule of thumb I like to use for splitting user stores is anytime you see the contractions “and” or “or” it is an excellent place to divide a user story into smaller stories.  In the above example, one eight-point story, when divided into three stores with an estimate of two, each generates less risk for the sprint.  The story split also makes budgeting work easier.

Splitting user stories is a useful skill, and it helps make the development team more successful.  Start breaking user stories today.

Until next time.