User story chainsaw massacre

The logical followup on my last article - Why not burndown tasks instead of storypoints? - about Tasks Burndown and smaller stories is obviously "how to cut those damn stories to pieces?". Unfortunately, no magic bullet here (yet?), this article is plain old Rubber Ducking (or Rubber Duck Problem Solving).

Say "no" to good-ol' beheadin'

The biggest problem about splitting big stories into smaller ones, is that the obvious cutting points (the neck and the knees ;) ) are often the most treacherous ones. If you face a multi layered application with some kind of UI / Services / Persistence structure, it is tempting to isolate those layers in different stories and treat them separatly e.g. cut "horizontally" and for example build the database manipulation in one story and the UI to show the data to the user in another.

Unfortunately, as Christiaan Verwijs writes in his article 8 useful strategies for splitting large user stories (and a cheat sheet), this has various negative effects:

• The stories don't deliver business value anymore
• The stories are even more interdependent which leads to even more bottlenecks
• The stories can't be prioritized anymore

So... #meh. The right and only way to cut stories is to cut vertically, e.g. remain feature-oriented and produce value while reducing the size of the stories.

Cheat Sheets

In my research, I found two cheat sheets that approach the problem in interesting ways.

The Sheets

The first one - from the above mentioned Christian - gives you 8 ideas how to view your stories from a different point of view.

Source: Christiaan Verwijs

The second chart basically presents the same information, minus the examples but highlights a couple important points.

Source: Agile for All - New Story Splitting resource

Cherry on the cake

Beside the direct usefulness of the cheat sheets in understanding how to slice stories, I particularly like the recurring message to pay attention to business value.

In the first sheet, the author spread out some "right-now" and "for-now" in his examples. In the second sheet (on the right hand side), the author asks two questions:

• Are there stories that you can de-prioritize or delete?
• Is there a story that gives you early value?

Those two points alone sum up a large chunk of the problems faced by the agile teams I worked with: they use agility to develop faster, with a better quality and will fit the customer needs better but they invariably have a hard time cutting the lose ends, saying NO! to features that don't bring (enough) customer value (right now).

And this, in my humble opinion, is the core benefit behind this whole agile and Scrum methodology. At some point, that your project is short on time or not, you will ask yourself "is it worth it to continue developing this software?" and if you followed this value first idea, saying "no" will be a viable option for a positive outcome.

TL;DR;

By cutting down stories to chew-able pieces you help the development process be more successful. But as a side effect, you will additionally encourage your team to think about the bits and pieces that constitute the product, ponder the importance of each of them and thus help the overall product grow in the right direction. So smaller stories? Yup, bring it on!