Product Development

Splitting stories like a journalist

When people are new to (agile) software development, I have found that splitting stories can be a confusing and difficult exercise for many. Splitting (also synonymous with slicing) stories is the activity of dividing stories too big for effective development into new, smaller, stories.

Many good techniques and tips for splitting stories exists already (some linked to at the end of this post). Yet, I’d like to introduce a simple alternative to splitting stories, that doesn’t care about story formats, software development terms, and other jargon.

Splitting stories using the Five Ws and How on the story’s solution, problem, and context.

“The Five Ws (sometimes referred to as Five Ws and How, 5W1H, or Six Ws) are questions whose answers are considered basic in information gathering or problem solving. They are often mentioned in journalism, research and police investigations.”

Five Ws – Wikipedia

Splitting stories like a journalist is asking questions, using the the Five Ws and How, to learn more about a story and expand our thinking about how it can be divided into smaller stories. The questions all start with either What, Why, When, Where, Who, or How.

Example: “Formatting toolbar”

To demonstrate how this might work, we’ll continue with an example.

  • What is the story about?”
    • “Oh, it’s a formatting toolbar. You know, like the one in Microsoft Word. Our users want to style their texts in different ways.”
  • Why do you users want to style their texts in different ways?”
    • “To improve readability and communication with their readers.”
  • What kind of different ways?”
    • “Well, we’re thinking a few. Making the text bold, in italics, different colors, and highlight words and phrases. That last one is often wished for by many.”
  • Who exactly wishes for highlighting of words and phrases?”
    • “That would be the editors. They want to be able to highlight certain words and phrases so that they more easily can provide feedback.”
  • Who are the other users?”
    • “The writers, of course!
  • How would writers like to style their text?”
    • “It’s the writers whom asked for being able to make their text in italics, and sometimes bold. To emphasize certain words, dialogue, and so on.”
  • When would our users use the formatting toolbar?”
    • “Writers use our service night and day. You never know when they get the inspiration for their next masterpiece. Editors, they’d would use it at work.”
  • Where are they using our service?”
    • Writers use all our applications. Editors, they only use it from their desktop computers at work. They don’t really care about the mobile app or web.”

What we learned from our questions

Alright. Before we continue, let’s take a look at what we’ve learnt already:

  • There are two kinds of users for the formatting toolbar: writers and editors.
  • Writers and editors both need styling options, but different actual options.
  • Writers use the service provided day and night, from anywhere.
  • Editors, however, only use the desktop app.

What’s next?

That should give you an idea about how the Five Ws and How can be used to explore and expand our understanding of a story. From this short conversation there’s already quite a few opportunities for splitting the original story, “formatting toolbar”, to smaller stories, which we then can ship one after another.

Since there’s also, in this example, fewer styling alternatives needed for each kind of user. A toolbar might even not be needed. Maybe there’s a simpler user interface that is available now that we don’t need as many styling options.

I hope that gave some ideas of how you can work with dividing stories into smaller stories. And when you’re ready to level up your game, I suggest you use the same questions on the story’s problem statement and context as well, and not just on the proposed solution.

If you have any story splitting techniques or tips to share. Please do, below in the comments.

Product Development

How sure are you that you’re building the right product?

For the last decade we’ve learned how to build products the right way. That’s great. It’s now time to ask: are we building the right products?

“There is nothing so useless as doing efficiently that which should not be done at all.”

Peter Drucker

If I were to ask you how sure you are that you’re building the right product — or feature — right now, chances are that you’re quite confident. You’ve done your research, talked to customers, talked to your team, and know the technology.

But what if I tell you that one third of what we build fail to show value. Another third has a negative impact on the value. And the last third may have a somewhat positive effect towards what you aimed for.

These numbers may not apply to you, but they did apply to Microsoft in 2009 (Online Experimentation at Microsoft). And I believe that says something.

With that in mind …

… let’s make a bet¹. How much are you willing to bet that what you’re building right now will show the value you hope for? Your lunch? That’s probably fine. What about a week of vacation? Or your car? Maybe your house even? Not enough? Alright, let’s bet your retirement savings.

Maybe now you’ve started to falter in your conviction that what you’re building absolutely will bring about the desired value. Personally, I’d say that’s a pretty good place to be. In the complexity of building products for other people we shouldn’t be too sure (and assume) that we’re on the right path.

So what can we do?

Experiment of course! List your assumptions, figure out what you need to learn, what decisions you need to make, what information you need to make decisions, and start experiments to get those answers, lower risk, and raise your true confidence.

I won’t go the details of experiments and learning activities in this post, but talk to your colleagues — chances are that someone knows something. That, or have a look at buying Strategyzer’s book Value Proposition Design. Tobias Fors’ Product Owner course bring up a few examples, and Jeff Patton’s talk Thud: Why it’s not failure you should be afraid of maps some activities to your level of confidence or risk.


1. Thank you, Jeff Patton, for the betting examples.