Stories that aren't

 Let's take a look at the "User Story Template" (also known as: Connextra Template, by origin) - "As a ... I want ... so that ..." - straightforward enough. It's common in the "Agile" space, and many inexperienced Scrum Masters and coaches learn that teams should formulate their work like this.

The result?

Formally it's correct. It's a "user story" based on the template. 

Now, what's wrong with it? About everything.

Let's leave aside for a minute the fact that this story is as much of an antipattern for "INVEST" as it could be, and focus instead on the use of the template:

1. The "user" isn't a "user". 

If we start calling developers "user", then next thing we know, testers, analysts, and project managers are also "users". It becomes a hollow, meaningless term.

A "user" is someone who actually uses the end product. 

Like ... a Candy Crush user is, for example: the "mother of a small kid who only has 5 minutes before the kids will cry again."

(Of course, developers can be users as well. But that would require them to actually use the product, in which case they wouldn't be a developer, but ... for example, a "mother-of two who sits in front of computer screens all day ..." - if that's your demographic!)

2. The want is a means, not an end

"Wants" should be something that this specific user wants to have and would be willing to use our product for, like "simple and easy fun". No user ever wants a Customer_ref_ID. Maybe they need it to identify themselves, but ... can you name anyone who wants to use a product because it has a Customer_ref_ID? 

Could you imagine running a marketing campaign with the slogan, "We have a Customer_ref_ID" - if not, then you're probably not addressing anything someone wants. 

Take it as a lithmus test for formulating "wants":

If you would feel weird to see it on a billboard on the way to work - it's probably not a proper "want".

 

3. The reason is self-serving and circular.

In more abstract terms, the reason is "so that I have it." - it doesn't explain which problems it solves.  It adds no information. It doesn't help us verify whether we're adding value to the product, and it doesn't help us verify whether we actually need it. It's a fake reason.

Let's, for argument's sake, assume that both the user and the want were valid: we still don't know why you want to refer to the customer by ID, and how that is better than what you're currently doing.

A good reason statement shouldn't repeat the "want", but explain why the "want" is relevant, which problem we're solving, how the world is better after the need is met.

Good reasons invite developers to understand why the user has an unmet need.