WIN #006: More Ideas for User Story Splitting

[click to enlarge]
Find more ideas for user story splitting in this issue of the Weekly Ideas Newsletter:

Look for conjunctions

Want to split a story, but find it hard to do?

It doesn’t always have to be that hard. A simple yet effective action to get you started is to look for conjunctions!

If not starting with it, stories should at least contain a “WHY” perspective. It serves to identify needs and pain points that story addresses through its implementation.

After formulating the story, look for “AND” and “OR” conjunctions. Each “AND” or “OR” conjunction is a possible splitting point!

Although not always applicable, this is an effective action to start with.

Here is a recent example I discussed with a client (rephrased on purpose here):

The story is about a user who wants to be able to set the Application language AND a Service Provider, in order to achieve a certain benefit.

The conjunction “AND” served as a discussion point to determine that there are two distinct needs with two different values to the user, leading to two smaller user stories.

Try it yourself!

The functional path is a story

Have trouble trying to split stories by functional paths? Struggling to even identify functional paths?

Take a look at the following example to gain a perspective:

Several years ago, Slack Engineering Blog featured a blog post including a flowchart of the Slack notification process.

Using the flowchart, one can navigate from the entry point all the way to the finish, using multiple different paths.

Each path is a single functional path.

But more importantly:

Each functional path is a distinct user story.

The diagram is most likely a result of the post-festum documenting of the process. However, it is a fine example of how to identify different user flows using a discovery process.

As soon as you have the paths identified, you can visualize them (using a similar flowchart,) and identify potential splitting opportunities.

Of course, many of these paths emerge only after the implementation has already begun. That is fine, too. Nothing keeps you from amending the chart and creating a few stories to reflect the newly-gained knowledge.

It helps avoid the common pitfall of expanding the story scope indefinitely.

(This tweet brought the flowchart to my attention)

An example

Want to try splitting stories but lack examples? Does it sound too abstract without an example?

Here is an example of a single functional path split from a larger story. As discussed above, the most straightforward way to split a story is to consider a single functional path.

The image here shows an example of identifying a single functional path.

Use your preferred way to formulate and structure the story (the Connextra template being just one of the options.)

It should not be an issue since you already have a reason (“WHY”) for introducing that functional path.

Don’t split into components

Wouldn’t it be great if the user story is split into components, so they can be reused?

Although tempting, this might not be that good of an idea.

Developers are often tempted to optimize prematurely and to make design decisions too early.

The usual response to the future-proofing desire is componentizing the solution too soon. Thus, developers often tend to create component-centric stories when participating in story splitting, while losing the real user’s perspective.

This often leads to impotent “As a Developer …” stories.

Functional paths help you cut through components while maintaining focus on user needs!

Build highly effective software development teams

Subscribe to the weekly ideas newsletter and get tips and insights to help you with building highly effective software development teams. You’ll get tips on how to do so every week.