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.
