Why As-a,I-want,So-that is Such a Bad Template for Stories - Part 3/3

Part 1/3

Part 2/3

3. The 5 Why's and 5 How's

Ok, but anyhow in case that "As-a, I-want, So-that" sentence does make sense, e.g. when the Who in What and in Why is the same and the only one persona, can we still write it down? I bet you'll ask this question because that sentence simply has such prevalence that there is almost an equal sign between it and the term Story, that you might even be concerned if you don't write that sentence, can that thing (e.g. the Jira item) you created be even called or recognized as a Story.

Unfortunately, as soon as you try writing down this sentence, as a one-line representation of your story, you will almost always be in immediate trouble with the "So-that" part. That's the 3rd problem I’d like to illustrate in this part. Let's see what that looks like with another example.

I'd expect that some audiences consider my example in the last chapter as non-typical, as they would expect stories for building a new product or a big-chunk module with many features, not a single, independent enhancement to an existing product. So this time let's try something familiar. Let’s say we were 20 years back in history and were going to build a first-ever online survey product. I could create a top-level story (usually since it's so big, we'll create an epic):

As a survey initiator, I want to conduct a survey online, so that I can easily access a wide audience and gather the survey data automatically.        

So far so good. Since the top-level story has a clear value, that makes a clear Why to be written down. Remember though there might as well be many other important Why's that needs to be written down, some even more important than that particular Why; whenever there are such Why's, it will be hard to fit them all into one So-that phrase, or simply impossible because there are different Who's inside, as previously elaborated. But let's leave those problems behind and go on with a few broken-down stories:

Sub-Story 1:

As a survey initiator, I want to create a survey online with ease and with support of various input types, so that (I am confident with doing it online?).        

Sub-Story 2:?

As a survey initiator, I want to share a survey online with ease and to multiple channels, so that (I can share it to a wider audience effectively?).        

Sub-Story 3:

As a survey participant, I want to access and participate a survey online smoothly, without being blocked or annoyed too much, so that (I will be more willing to participate?).        

I hope you can already see that I was struggling with the "So-that" part for all the 3 broken-down stories. In fact, I'm not sure what I wrote was even meaningful. That's because what each broken-down story corresponds to is a partial feature scope of an already defined solution. The purpose of each of those features is quite straightforward and inherent in the feature designs themselves. That would mean in real life we often don't see a need to write the "So-that", if not repeating the What or Why already stated in the parent story. Whenever we try doing so, we find it awkward, like the above. In the example above, those 3 sub-stories combined are already a designed solution of the top-level story, and the Why's (e.g. why the solution is composed of these 3 features but not something else? ) have already been asked and answered in the top-level story. That's why we would break it down into these 3 stories but not anything else.

While in each sub-story, there usually are plenty of lower-level Why's to answer and note down (e.g. why the feature is designed in such and such a way, but not in other ways), but hardly anything to write about the story itself (e.g. why we even need this feature). That's why my So-that's looked so awkward.

?

Some might suggest writing the sub-stories as follows:

Sub-Story 1:?

As a survey initiator, I want to create a survey online, so that my survey is equally good or even better than offline, with great usability and the support of various input types.        

Sub-Story 2:?

As a survey initiator, I want to share a survey online, so that my survey can reach a wide audience via multiple channels with efficiency and effectiveness.        

Sub-Story 3:

As a survey participant, I want to access and participate a survey online, so that I won't be blocked or annoyed too much.        

Please notice that instead of asking the Why or the purpose of the feature, the approach above states in the "So-that" part the goals or target results of the feature. That pattern is commonly seen in real life. But we have to admit that what it really does is to avoid writing a meaningless Why, and just to shift something from the What to the So-that part. I'm not saying that the design goals/target results are important things to write down. But those things are a key part of the solution/the feature design, and don't have to be packed into a "So-that" phrase and be confused with the answer to the question why we ever need this feature.

But sometimes however, if it won't mislead you, there could be a meaningful Why for a broken-down story (as for why we need this feature at all). Here's an example:

Sub-Story 4:

As a survey initiator, I want to login to the online survey tool, so that my surveys and the collected data can be saved and revisited and managed anytime later.?        

Here the "So-that" part does reveal a valuable insight*. It might seem apparent that a web product needs a login feature. But it's not always the case when you think twice. For example, a weather info website or a personal website may not require login. In this case, it's indeed questionable whether or not a survey participant would want to login at all. And its answer might determine whether we will build this feature at all, and also impact more or less how this feature is actually designed. (nonetheless, that still may not be the most important insight to note down for the story)

My point is, when a sentence with a “So-that” is written down to represent a story (i.e. a feature scope), then the "So-that" would naturally be a Why as for why this particular feature is needed, why not a different feature or why it’s needed at all. Even though sometimes there is a meaningful Why to ask as in sub-story 4, for most broken-down stories it usually is self-evident or inherent in the parent story or the wholistic solution's design, thus not meaningful to write anything about.

What I'm saying is that even though it's quite common that you don't need to or simply can't write the Why, because of the practice of writing that "As-a, I-want, So-that" sentence to represent a story, people are forced to write a meaningless "So-that" or confuse themselves by writing something else from the "What". And the saddest fact is that sometimes it does make sense to ask a Why, like for sub-story 4. But the people who invented that magic sentence simply assumed there's always a meaningful Why to ask and to write down.

My job here is to demystify the magic sentence, pointing out that the "So-that" part is a careless design rather than a best practice. Because there's nothing special with asking why. There could be one Why, or many Why's, or no Why at all to ask. When designing a solution, you anyways have to ask and answer not just one Why, but all the Why's necessary (like the example questions I listed for "why it is a problem worth solving" and "how you decided on this particular solution"). There might be nothing to write about or repeat at the story's own level, since it has been clarified on a higher level being part of the overall solution, like it was for Sub-story 1, 2, and 3; there might as well be many things to note down in the story (but then they won't fit into a single "So-that" phrase; only when it happens that one and only one reasonable Why is worth noting down, like for sub-story 4, will that magic sentence appear to work).

To nail it further down and to make it more natural for you to understand, let's look at how the Why's work in our problem-solving journey.

You must have heard of the famous 5 Why's technique, which basically means asking "Why" 5 times recursively in order to uncover the root cause of a problem. In other words, each time we ask Why, we go one level up and identify a more abstract problem, while the previous problem is nothing but a solution (among many other possible ones) to this higher-level problem. In that sense, whatever we define or write down is always a “What”. There’s nothing else but What’s on different levels. A What on the parent level is a Why to the What’s on a lower level. And the What’s on the lower level are the How to the What on the one level up. What a product team does in problem-solving is keep asking How and answering by defining the What's on lower levels until it hits the concrete ground.

So when we identify a target problem-to-solve, we not only will ask multiple Why's to understand the problem deeper and better, but also will ask How's to come up with the best possible solution. At any level, we might ask various different Why's (e.g. Why is it worth solving? Why now? Why us? Why not solve a different problem?) and various different How's (e.g. How we decided on this particular feature but not a different one? How is this feature solving the problem? How well? to which degree or scope?). The Why's might reveal several related problems and similar problems, or even challenge the legitimacy/necessity of the What itself (like what we asked for sub-story 4: why is login even needed for an online survey tool?); the How's would also bring up not only one but multiple candidates as the solution, which require a careful decision to make.

Coming back to our topic, what I want to point out is that the Why's are not part of a story's definition. A story is only created to represent a certain piece of feature scope of a solution (i.e. a "What"), meant to assist planning and execution. It is not meant to help with clarifying the problem nor the designing of a solution (i.e. asking and answering the Why's and How's), which take a procedure of its own, for the three Amigo's to constantly work on. That’s why the magic sentence, with an unnecessary "So-that" phrase, has a trouble with representing a story or serving as a story’s definition. It's not just that it is redundant and can be simply ignored, but that insisting on writing it causes confusions and illusions that could prevent us from creating meaningful stories and writing down the real important things.

And as previously explained, the magic sentence is also not needed, nor suitable, to describe or document the problem-to-solve, the solution, or the answers to the Why's. So in conclusion, we should never write the "As-a, I-want, So-that" sentence in our stories, so as to avoid all those problems depicted above. It's really time for us to break with this stereotype and to put all our attention on what are really important. And write them down in the way they need to be.

?

And let me close this article with one more diagram illustrating how stories are really supposed to be used:

When a product team works on a problem-to-solve, they eventually will need to make something happen in reality. For that, they will ask Why's and How's, and keep going down of the "What" ladder until they reach the ground. At certain level, a story (or usually an Epic) will be created to represent the whole problem-to-solve (already clarified, derived, materialized, and maybe already several levels down the original problem). Then it will be broken down into multiple sub-stories, covering the different aspects of the solution, maybe assigned to different sub-teams or people to work on. And a sub-story could be further broken down if its scope is too big or takes multiple phases to build. The team continues on asking How's and creating lower-level stories or backlogs, until eventually the What hierarchy lands on the ground, where a developer decides on how to code, test, and release a piece of feature. All the What's on the ground level combined is a real-world solution delivered. And the whole "How" movement is the planning and execution of a product team, which the stories are created for. Stories are only the What's; they are the results of the Why's and How's. They are created when we have answered the Why's and How's so that something real can then be delivered accordingly. Their value is to assist us on planning our team's work so that we can eventually turn an abstract problem-to-solve in the air into a concrete solution in reality.

?

What makes a good story?* As long as it serves well its real purpose and avoid confusing people, as long as it notes down the real important information, you are free to write whatever works best for you. But just don't write that magic sentence!

*?? I found it important to point out this subtlety as it is where one of the biggest illusions of the magic "As-a, I-want, So-that" sentence comes from. The illusion is that it seemed that important insight was revealed only when you asked this additional Why to your sub-story 4, proving the virtue of that magic sentence. It's the same illusion you might have with the "As-a" part, which seems to be emphasizing: "Don't forget the target user"! It's as if it was due to the reminding of that magic sentence, you are forced to clarify the Who and Why, or you might have missed certain crucial insights and thus defined a wrong story, or rather, designed a bad feature. But the truth is, the target user and the valuable insight (or even multiple insights), together with all other important considerations, should already have been clarified and concluded before the story gets planned. And it's not just one additional Why we need to ask and answer, but multiple and various kinds of Why's, such as our rationale for why we decide to build yet another survey tool, why build it ourselves, why build it now, what's the ROI analysis, etc.. You've also seen some most common examples of Why's listed in my story template at the end of Part 2/3.

?

*? Are there criteria for good stories? You might also have heard of (been poisoned by) a principle called INVEST. While I don't see it helpful at all other than helping itself (to become a famous acronym), it does add a lot more confusion to people's understanding of what a good story should be like. What I hate the most are the letter I and letter S, which stand for "Independent" and "Small". We all know decoupling is a good thing but is it always possible? And isn't it true in most cases the broken-down stories are dependent on each other? Does a story must be small enough to, say, fit into one sprint? Then we'll certainly be forced to use Epic for any bigger stories (but then you will of course struggle with writing a meaningful So-that for your small stories ;) . And what troubles could a big story across multiple sprints really cause (in practice, I prefer to have a story represent the scope of one releasable feature delivery, and use Backlogs to represent further broken-down tasks assigned to developers)? Let's please save all those unnecessary extra struggles in fitting our stories to criteria we don't understand. Just create one when needed, and only write what's meaningful.

All rights reserved by Tao Zhang