|Splitting user stories require creativity and the right tools.|
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.
The rule is simple, and the team says following SOLID principles and authoring unit tests it would be two points worth of work.
GIVEN I am a customer. WHEN I purchase a 30-second commercial. THEN I invoice $150 times the number of commercials purchased.
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.
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.
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%
Splitting user stories is a useful skill, and it helps make the development team more successful. Start breaking user stories today.
Until next time.