Why As-a,I-want,So-that is Such a Bad Template for Stories - Part 2/3
2. The Who, What, and Why
You may ask: OK, I understand a story cannot be implementation-free. But could we still use that sentence to describe the feature, in a way like the following?
As a <persona>, I want to <perform some task>, so that I can <achieve some goal>.
That is like a step in a user journey, spoken from the mouth of an end user/persona. If we refer to the three parts as the Who, What, and Why, we could say that the What corresponds to the feature description on the high level. And then obviously the Why should correspond to the problem-to-solve. Would that work? Unfortunately, that approach still has severe problems.
Problem 1: there might be multiple persona's and they all need to appear in the feature description. So that one sentence simply doesn't work in such cases.
Problem 2:? the Who is also an integral part for the problem-to-solve (as for whose problem it is). Now it is split apart by the What. Worse yet, it could even be different to the Who at the beginning of the sentence.
?
Your first thought might be: those are the limitations of that one sentence and could we simply solve them by splitting it into 3 sentences?
Who: <the persona's>
What: <feature description>
Why: <the problem-to-solve>
That is also what's preferred by Jeff Patton in his book User Story Mapping. Unfortunately, as long as you write those 3 things, a severe confusion is already introduced. That confusion is around our intuitive understanding of those 3 abstract words.
First of all, if you agree with me on Problem 1&2, then it should be clear that the Who should not be taken out. Both the What and the Why will always require the Who inside of themselves. Yes, I know it's to emphasize the Who, to say that "let's not forget about the target user". But in real life, I never encountered a case when I can avoid mentioning the target user while describing a feature or a problem. It's actually harder for me to phrase my sentences with the subject decoupled, let alone the cases where multiple persona's are involved or where the end user using the feature is different from the target/owner of the problem-to-solve, who might not even be a persona. Here's an example:
We recently planned to work on supporting custom domain. The problem-to-solve is, quite a few of our customers requested that our software should be accessed via a custom domain (e.g. hr.apple.com) which is owned by the customer themselves, instead of what we offer out-of-the-box like www.hr.sap . Yes, I know that sounds boring but it is also real life and we product owners don't always get to work on fancy topics (and I won't mention here topics like role-based permissions, data privacy protection, accessibility, public API, developer tools, etc. which takes a whole chapter to even explain the concepts). Anyways, this topic itself is of high value and urgency to our product as it's a go-live blocker for those important customers and hopefully many potential customers on the way. Our conclusion, after careful evaluation and joint discussion, was that it is definitely a thing worth doing. It's going to be quite cheap to implement, per technical design and validation and the benefit would be huge, considering the deal sizes of those big customers. So the ROI would be really high here. We then created a story for the implementation work to be planned into the next sprint. Our solution is as follows: we will simply add a feature toggle, which will be turned on and configured to a given custom domain, per requested by any such customers, by our support team on an existing internal admin UI. We decided on such an approach because we know it's going be the cheapest and fastest way to achieve our goal: the scrum team can deliver the change within one sprint, while our company anyways have a support channel in place and customers anyways will need our support team's engagement during provisioning their tenants. We are certain it's going to be totally acceptable by our customers, since they anyways need to express their ad-hoc requests via our support channel while it doesn't take them any effort or risk for setting up such a configuration. And it's also acceptable to our support team who have confirmed it won't be too much additional work for them.
Now, try fitting such a story into the Who, What, and Why.
If you say that the persona is a support team member, it seems to go fine with the What, as it is the support guy who will turn on and configure the custom domain feature on the internal admin UI. But then it won't work with the Why, because it's not the support guy's problem-to-solve.
In this particular case, the "As-a, I-want, So-that" sentence seems to work better, as you could write "As a support team member, I want to turn on and configure the custom domain feature for a customer on the internal admin UI, so that the customer can make our product only accessible within their private network". But then it's not that "the persona wants something", but it's "the customer wants it". That makes this sentence so misleading, as it makes it as if it is for the support guy, but for a customer. And believe me in many cases, this little ambiguity leads to big troubles. Someone might tend to write "as a customer, I want …, so that …". But a customer is not even a persona, so with customer as the Who, we could only describe the problem-to-solve but not the actual solution in the What. That's how all the struggling comes about. It might seem minor, but in the end, we simply can't write that sentence in a consistent way, and can't share the same understanding and expectation on that sentence with our team. That's the exact awkward feeling I might have evoked from your memory with the opening speech of this article, I guess.
The crux of the problem is now clear (and quite simple): the Who is always needed in both the What and the Why, and it can be different Who's for the What and for the Why. So why can't we just have the What and the Why, but not the Who as a third (and even the first) item, since it's anyway included in the What and Why and sometimes even impossible to be taken out? What I would propose is that we start with describing the problem-to-solve, then describe the solution we have decided to build.
In addition, you must have noticed from the example that there are actually quite a few other things (besides defining the Why and What) going on. Those are the key assumptions, investigations, analysis, considerations, and conclusions that we took to eventually decide on making that investment now. In my opinion, you should never save your time from writing them down in the story besides the problem, the solution scope, and the AC.
领英推荐
If you don't, it might mean two bad things:
Here's a template I use for stories in my team:
Motivation
Describe the problem-to-solve/job-to-be-done, e.g.
Explain why it is a problem worth solving, e.g.
Scope
Describe the features (on the high level) you are going to build as the solution to the problem.
Explain how you decided on this particular solution, e.g.
Specification
UX Design: Link to the design mockup, if applicable.
UA Info: Link to the strings file, if applicable.
Technical Design: Link to ADR, if applicable.
Acceptance Criteria: bullet points on confirmed details on all aspects of the feature, including non-functional requirements
That may seem a lot to write down (or to "document") for each story. But note that the bullet points are just examples and completely optional for you to use. Also as said, 50% of the case you are creating broken-down stories, which don't need the Motivation section at all, and the "Explain" part of the Scope section can be very short.
Read along for the last part where I will talk about not the problems inherent in the sentence but how it fits to the purpose of a story.