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

Tell me honestly how you feel so far about writing that "As-a, I-want, So-that" sentence.

If you have never had friction, confusion, questioning, or if it always goes very smoothly while being helpful and valuable to you, you are not like me and probably most product owners in the world.

I don’t know how this template got into popularity and became kind of a de facto standard. But I would guess it’s somehow like this: when a newbie product owner tries his hands to write his first story in Jira, he might only have one word in mind: “requirement”. After all, it's his job here to define it, per his rudimentary understanding of the product owner role's responsibility, and what other people in the team are expecting or asking from him. So how do I describe a “requirement”? Then that sentence pops up: "As a …, I want …, so that …". Yes, that sounds perfect and he even couldn’t manage to find any other better alternatives! It is great because I speak of the requirement from the target user’s own mouth! That’s something really worth emphasizing to those who don’t even understand or care about the real customer values (as for why we are even building this feature and who is it really for), for example the developers in the team who are going to read it and to stand facing it in every scrum meeting!?

Anyways, you started writing your stories with that template. And soon you found it didn’t go so well with probably half of the stories you created. You either struggled a bit with fitting the right things into the sentence, or found the sentence not that valuable to the story, at least not helping with what you really needed to clarify in the story. Why was that?? Why I always find it necessary to write many other things in the story while the "As-a, I-want, So-that" sentence, in many cases, doesn't even seem relevant, sometimes even look quite awkward?

Then you started learning more Agile theories and reading some books (for example User Story Mapping by Jeff Patton, User Stories Applied by Mike Cohn) and reflecting based on your own experience with writing and using stories, until you developed much deeper understanding of the product owner role and wondered about the real meaning of stories: Why stories ever need to be created? What's the purpose of doing so? What are they really for?

?

Stories are used for planning and execution, not to document requirements.

?

Above is my answer, and what I found most crucial to point out to those who are still struggling with writing that magic "As-a, I-want, So-that" sentence in their stories.

You can STOP it now!

In his book User Story Mapping, Jeff Patton compares the "As-a, I-want, So-that" template to Snowplowing, a gesture good for beginners to learn skiing. But I don’t even think it is good for beginners, nor for anybody. Because it does more harm than help. It causes confusion from day one, when clarity is needed most.

So let’s look at the main troubles brought by that sentence while explaining the true meaning of stories.

1. The Myth of "Requirement"

That term "requirement" and its mysterious closeness with that sentence leads to a most typical illustration like this: As a <persona>, I want <goal/purpose>, so that <reason/benefit/value>. It is said that this sentence is to clarify the so-called “requirement” and therefore should stick to the “problem to solve”, not to any actual features to build. In other words, it is supposed to be “implementation free”.

Another reason why such explanation gets its way is the emphasis on outcome over output, per many agile and product theories. Yes, it is absolutely right and important that you and your team should not be confined to, or only pay attention to, feature delivery but should measure their success by customer values and business goals. But the next question is, given that those business goals are clear to everyone, how your team would get to deliver anything, and then how to execute efficiently enough so that the business goals can ever be achieved before the team's limited resources (time and capacity) are exhausted. That’s the real challenge why stories are created for. I'm not saying that clarifying the business goal is not important. I'm saying that stories are not invented for that purpose. Stories are a tool for better planning and execution, not for clarifying the business goal (or the so-called "requirement”, the "problem-to-solve", the "job-to-be-done", the OKR, … whatever you call it), which is just the starting point of any execution. The "requirement" itself takes a separate (and different) process to clarify, validate, and prioritize (which I will talk about more in another article),? which might not at all be best described by that "As-a, I-want, So-that" sentence. But then for execution, it means we won't necessarily need that sentence to be written down, especially in a story (on the other hand, there are some other things that are too important to not be written down).

Nor does every story always have to correspond to a measurable business outcome. When you look at techniques like User Story Mapping, you'll realize that stories, especially broken-down stories, could be very far away from the "problem to solve", but way closer to how you want the execution to actually go. You will constantly find yourself fitting stories into timelines, splitting them into multiple phases, breaking them down into smaller pieces so that your scrum teams can take into sprints, assembling them into a walking skeleton and then gradually adding more flesh until it's production-ready, so on and so on. All those are very natural and common things to do with stories. There's nothing wrong with those operations because stories are meant for them. For execution we simply need those different stories to be created, and be used to plan, organize, track progress of our work. But for many broken-down stories, it often would be simply absurd to write a "As-a, I-want, So-that" sentence for each of them (as they might as well share the same "requirement"), or to insist that every story must be represented by a meaningful, integral "requirement", written with that sentence. That's where most of our struggling I mentioned at the beginning of this article comes from. One common example is if one story requires the work by two teams from two locations or product areas, then we certainly will create two broken-down stories for each team corresponding to their own part of the work*.

And let me go even further: when it comes to execution, we can never plan a "problem to solve" without talking about its solution. In fact, before a story can be planned and assigned to a development team, the actual solution must already be fully designed, validated, and aligned among the 3 Amigo's (PO, UX, Engineering). Questions like "what exactly will be built?", "what is out of scope?", "what are the different options and why we chose this one?", "how much does it cost to build and maintain?", "why do it now but not later", etc. must all have been answered and agreed upon. Can you imagine that a product owner creates a story and walk away with only the "problem to solve" clarified, but without even checking whether any technically feasible solutions do exist? And if the only possible solution takes 10 years to build, the planning would be of course in vain. So what are the things that must be clarified when creating a story? There are actually quite a few, e.g. the UX design, technical validation, architecture design, maybe even some direct customer validations/feedbacks. But among them:

?

The (feature) scope is the first and foremost thing to clarify and write down in a story.

?

In fact, in order for the scope to be clarified/finalized, most of the other things will need to be already looked into or even ready. But why I emphasize the concept "scope", is because that's what we concretely plan for execution. Without that, a problem remains a problem in the air, and it is still totally open as for what we will actually do to solve it. It takes non-trivial efforts and iterations till we reach the point where we are all confident and aligned on a concrete feature, with the delivery of which the problem is considered solved, to an acceptable degree, within the limited resources and a certain timeline. Without the scope being finalized, it won't be wise for the scrum teams to start writing any lines of code since the feature definition is subject to change. So even if you create a story and plan it into the current sprint, the actual execution won't begin and the story will still remain in planning phase until the feature scope is finalized. In the next article, I'm going to talk about the natural phases of a story and explain why they exist and what to expect from each of them. For now, I just want to point out that the scope, in terms of the (high-level) definition of the feature to be built, is the real core of a story. You simply cannot execute without it (but you can, without that "As-a, I-want, So-that" sentence).

?

Stories were invented as an agile technique to avoid the previous notorious document-driven waterfall software development process. So it’s widely accepted that a story isn’t meant to be a document with lots of details. Unfortunately nowadays stories tend to be too short, sometimes even with only one sentence, thanks to that template, missing many other crucial information which as time passes by get lost/forgotten and hard even for the same people to recall. More often than not, you'll find your team touching an existing feature which was built one year ago and no one could remember why it was designed as such, why it was decided to be implemented to such an (limited) extent, under which key assumptions (let alone knowing whether they still hold true). It then won't be that easy for you to design new features or changes on top of it. Compared to the amount of details that we will anyways note down as the feature scope and the AC (Acceptance Criteria)*, I definitely believe we shouldn't save the effort of typing down those key information into the story. Unfortunately, many people now seem to believe that the "As-a, I-want, So-that" sentence is all what's needed to be written down in a story (I'm guessing it probably started from the "3C" (Card, Conversation, Confirmation) theory, where you only have the space to write one sentence on a Card).

?

Till this point, I hope I've made it clear that the "requirement" or the problem-to-solve isn't the only thing to expect from a story, nor do stories exist for its sake; it doesn't even need to always be there in a story. What a story really represents is a (already designed and chosen) solution to a problem that we have decided to solve. I've also briefly mentioned the other things that are essential to a story, and therefore worth noting down. At the core, it is the solution scope that must not be absent, incurring all the design work that must have happened before a story can be planned for execution, which is the true purpose for any stories to be created. And it then will be so natural, and so often needed by planning and execution, for a story to be broken down into smaller ones, each with only a partial scope but without the need to repeat the "requirement".

Read along for Part 2/3 on more problems inherent in the "As-a, I-want, So-that" sentence and my thoughts on them.

?

* You may ask why can't we use two backlogs instead of stories? Well yes, but they are just different names. The point is we have to break a story down for various reasons, and even for multiple times/levels. But only the very top level story could correspond to a wholistic "requirement" (often still only one aspect of the whole problem to solve). If you say everything below the top level should be called backlogs, then the majority of our Jira items should be backlogs. In my daily practice, I prefer using backlogs to track the actual development tasks, and leave them for developers to create. While on the highest level, we use epics to represent the wholistic "requirements", which are closer to the roadmap items which usually require a significant investment. And you see, there's no clear boundaries for an epic, a story, or a backlog. And definitely it wouldn't make sense to say that a story must carry that "As-a, I-want, So-that" sentence, while the other two types don't.

?

* Could the Acceptance Criteria be used to cover the feature scope? No, because the AC are too granular and their job is to note down the nitty-gritty details, even to serve as basic test cases (especially when BDD is applied in your team's development practice). The feature scope is a high level description of what's going to be built as a solution.

?