Writing “As a User” does not make it a user story

I got a question from one of the blog readers on how I would describe a spec with examples for a user-interface specific user story, such as “As a user, I want to register in order to log in”. The reader challenged the value of doing a Cucumber test for the registration, because it’s obvious and mostly UI-heavy. First of all, there is nothing obvious about that story. In fact, that is the problem! I wouldn’t even try to describe the spec for it, because that would just be continuing a garbage-in-garbage-out queue. A good user story is a necessary input for a spec workshop. A good user story is one that helps the delivery team reach a shared understanding on what it is about, and that helps the team discuss the needs with their business stakeholders. “As a user, I want to register …” fails miserably there, because it is a lie.

The lie starts with the whole premise. “As a user, I want to register”…. No I don’t. As a user I don’t want to give my private information to another site, have to argue with some arbitrary fascist filter about which combination of letters and numbers is strong enough, try to guess what’s written on some random distorted image, and then have to remember another set of fake privacy answers. That sentence might be in a user story format, but it’s far far from a user story. It’s grammatically correct, but completely false, just like saying “As a citizen of Greece I want to pay my tax so that the EU stops giving us free money”.

As a user, I will suffer registering if it brings me some value, but I don’t want it. As a user, I might want to store my files securely online, to limit access to my data, or to do something else… But registering, and for that matter logging in, is very low on my list of priorities. And that’s where we run into the problem: the lying “user story” misleads teams into wasting time on discussing things that don’t matter that much. Because there is no context, there is no way to know when we’ve done enough, so unnecessary features creep in. Because there is no real benefit there, the “story” will lead to a feature which, on its own, won’t be particularly useful. A team can demo it at the end of the sprint, but there is zero value in it going live on its own. To get real feedback they’ll have to do who knows how many more fake stories, with more feature creep.

A more realistic description of what the users really want to achieve would be better, because it would limit the security aspects to what is really necessary and prevent unnecessary bloat. It might lead to something shorter, shaper, deliverable that would actually bring value. A more realistic description of who really wants this might lead to a realisation that it’s not the users who want to register or log in, but possibly the web site operators who want to identify users so that they could charge them correctly, or compliance officers who are concerned about privacy complaints, or marketers who want to harvest e-mail addresses. None of those motives and needs are captured in the starting sentence, so they won’t be discussed or implemented at the same time as the silly log in form. It doesn’t matter what you write in the spec or test for this user story, it will fail to deliver.

Stories like this are fake, misleading, and only hurt. They don’t provide a context for a good discussion or prioritisation. They are nothing more than functional task breakdowns, wrapped into a different form to pass the scrutiny of someone who spent two days on some silly certification course, and to provide the organisation some fake comfort that they are now, in fact, agile. Don’t fall into that trap. Challenge your user stories, scrutinise them, and make sure that they capture real stakeholders and their real needs. This leads to much better systems, and much happier users and stakeholders.

For example, MindMup allows people to store files online and come back to them by generating random URLs and storing the references in the local browser profile. No log in and no registration required, and our users love us for that. We got to roughly 140K users now, without ever needing to have a database, which means that the system is cheaper to run and has one less point of potential failure. It’s a win-win scenario just because we were realistic about what our users want. Registration, the first thing that most teams do when building a web site, never really came into the plan.

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. I'm currently working on 50 Quick Ideas to Improve Your User Stories. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Specification by Example Workshops

Product Owner Survival Camp

Conference talks and workshops

16 thoughts on “Writing “As a User” does not make it a user story

  1. Hi Gojko,

    a good post. I generally dislike the role “user” in a User Story since almost every role is somehow a user of the system.

    Best regards,
    Alex

  2. Nice post. I am developing a client portal for a fond investment company. Basically people give their money to this company which then invests it. Each new client automatically gets an online account from them which it can then use to login for viewing several kind of details about his investment.

    In this case, how would the user story look like?

    “As a customer I would like to use my credentials to login to the portal for viewing my investment details.”

    Something like this? Would that be fine? Because also here…what the customer really wants isn’t to login but to see the status of his investments..

  3. @Gojko Great post! I’ll be using this in my coming training courses.

    @Juri Maybe something like: “As an investor, I would like private access to my investments, so that only I can see my investment details.”

  4. @Gojko: Sharp observation! Good post. A couple of months ago a team I was helping was hassled with the user story: As a user I want to make a payment in order to pay my bills. Since this happened at a bank I commented that I hoped this user story was already done back in 1873. At first they didn’t understand my comment, but we ended up with a complete different user story unveiling the true reason, namely the bank needed to be compliant. The user did not want anything more he or she already couldn’t do.

    @Juri I think Jeroen’s user story is pretty spot on. This can result in other solutions like Gojko explained for mindmup.

  5. You start this post by saying “First of all…” and go on to wonderfully describe one reason why so many user stories are anything but.

    Having read the post a few times, though, I think you never quite got around the “second” question posed by your blog reader. They may still be wondering what the value of Cucumber tests for UI-heavy features is.

  6. interesting… security stories for some organisations are very important, but I find projects going from bad to worse because someone feels its more important to waste several sprints arguing over the finer details of the secure registration and authentication than actually delivering the valuable nuggets of functionality within.

    For the most part security is part of the architecture and comes out of the development process as one person said, though with one project and the industry compliance associated it was a very valuable thing to have in place.

    There is a need to capture the requirements for registering for a service and providing a means of customers to authenticate themselves and by this in one environment was more than just a username and password it had to be two phase authentication (something you know and something you have).

    What I hate to see if the priority being based on the user journey and not the value of the function, so for a banking application the journey may begin with registration and authentication but the value is in performing some banking, like seeing my balance and making a payment.

  7. I think the responses somehow miss Gojko’s point on the matter. The subject here is not especially about login procedures or security issues but is more about catching the spirit of what a user story shouldn’t be and what it has to be.

    @Gojko could you please give some more examples on issues other than login/security stories. For example currently I’m both the scrum master and test team lead on a DCIM project and I’m pressing our PO to write user stories about every aspect of our current PBI’s. Our current PBI’s aren’t in story format but instead they are formulated like technical module descriptions. I have to convince him to write stories for modules like asset entry, SNMP group definitions, asset tagging, reporting features, live sensor reading graphs, system alerts etc. What he comes up when I ask him to write stories is just a detailed reformulation of those technical descriptions. How can I be of help to him to make him see things differently.

  8. Pingback: Customer First Development | mutable thought

  9. User stories such as the one you discuss are often written that way because people want to describe the intended interaction between some person (i.e. the user) and some system. Use cases, the more elaborate ancestors of user stories, explicitly name “actors”.
    I think there is some value to keep it like that (i.e. name the actors in the user story), at least when we’re down to discussing with the team about the development (construction phase) because it helps people understand the intended interaction. I wholeheartedly agree that it is necessary to drill down to the real need that some requirement is about and to use the best wording possible to discuss the business value of a story or feature.

    What we did, in a very similar case, was to slightly change the wording from “as a user, I want to register to ” to “as a first time user, I need to register before I can in order to “. We then had more detailed requirements (e.g. the detailed password policy) in separate misuse stories that were described from the perspective of a potential attacker, e.g. “as an attacker, I cannot use a simple dictionary attack to hijack accounts”. The acceptance criteria then detailed the requirements.

  10. I couldn’t agree more. Another example I came across: “As a Dating Site Member, I want to create a profile so that other members can find me”. This one was particularly difficult because most members don’t mind providing basic info but baulk at answering the massive amount of questions that almost all sites present.

  11. This post is spot on. A user story should convey context and value, and the value derives from actual problems it solves or avoids for the user or buyer (a.k.a. “requirement”). If you can’t discern what problem a user story addresses, there’s probably something wrong or missing from it.

    However, there is another legitimate way of dealing with these issues, IMO. We can use story decomposition to simultaneously capture the context, the value, and some of the interaction design that realizes the value.

    @Gojko, I’m curious what you think of this blog entry on epics and user stories, and how we can structure them to address the issues you’ve raised here.

  12. @Gojko – thanks for this post. We have run into this in my organization, in part because we are “young” with regard to user stories. It seems like “naming the actor” can help out, as well as capturing exactly what that actor wants to accomplish (@Holger I like your ideas).

    We had some interesting conversations on a recent feature that falls into these traps. We have a data aggregation system (collecting and displaying information from different sources). The core story is “As an employee, I want to see all the projects I am working on,” where the project information is stored in different databases, etc…. However, we ran into the concept of frequency — does the employee need to know those projects in real-time (up-to-the-minute), or on a daily basis? So we tied that into the story, something like “as an employee, I want my data to be copied once a day.”

    This is of course a poor story, in that the implementation is stated in the story. But it took some work to get to that understanding, because we were uncertain where to include (or whether to include) that type of detail. Maybe it should be part of the story decomposition: “I want to see my projects, and I expect them to be correct within 2 business days.”

    I would be interested in tactics that can help us move towards cleaner story designs.

  13. Pingback: Customer-First Development | DevFacto - Edmonton, Calgary, Regina

  14. I think this is key – writing a story YOU want “from the perspective of” one of your real users, can be very different from a story of what your real user wants. Frequently, the only way to discover that is by talking to them!

  15. I agree that the “As a user I want to Register so I can Login” story has a smell to it. But I think it’s not completely useless when written slightly different.

    Here’s a story I wrote for a hobby project:
    “As a User I would like to be able to register an account so I can be recognised by the system”

    For my application “The System” needs to be able to authenticate a user so eg. the stored information can be retrieved on different devices (mobile, desktop, whatever). So the added value to a user is that they need to have an account in order to use the information on different devices.

    A real world analogy would be a Passport. A Passport by itself doesn’t add any value. But since a most of the countries require you to have one that you can use to authenticate yourself, it suddenly adds value.

    User Stories without context are not very useful. So you have Epics to add that “Business Process context”. And I think Roger L. Cauvin already mentioned that.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>