There Is Nothing Wrong With "As a user" Approach

Feb 26, 2018 21:59 · 969 words · 5 minute read user story scrum requirements

As a customer, I want to access the application to make an order.

How does that sound? Is it to dry? Do you need to know more about person trying to make an order? Is it fun enough to get cracking the code?

Recently, I came across a great article saying that As a user approach is not the way to go about stories and suggested a more empathic approach. The author argues that we’ve become detached from the real people who will be using the product or software.

I can’t disagree more. The article makes few excellent and valid points but interprets it in a wrong way. I see where the author is coming from: it might be a right way of thinking about interfaces from the standpoint of the concrete middle-age single Joe with two cute daughters who is aiming to buy them a pizza. But this approach has absolutely nothing with development. Few stories such as that could be used early in the project to draw a big picture of the product, but I don’t see them being any useful even after a few weeks down the line the project.

Story is not a novel

There is an example presented by the author:

As a user, I want to log in, so I can access the application.

Indeed, this story does not tell anything about the user. Right on the spot! However, adding details such as age or hair color won’t help either. Not to say that the story should not list the devices that the user is trying to log in with. Forgot password, single sign-on - all these shall be separate stories.

The story above is terrible, but not because it is boring or doesn’t look like an essay. There are few particular things I don’t like about it, namely:

  • a user is not definitive. The actor must be referenced explicitly as a user type. For example: a customer, an anonymous user, an admin and so on. It is a good idea to outline all the user types and reference them. But I will come back to this later.

  • I want to log in. It isn’t that bad actually. This particular example, however, is too vague, indeed. If there is only one way of signing up, this should be alright. However, if more options are considered, then having something like login via Facebook will be way better. As an alternative, an epic Authorization mechanisms could be created. Nevertheless, you may choose to go into any level of details with the user story depending on circumstances.

  • I can access the application. Janet Taylor makes a perfect point that the story doesn’t answer the question why the user wants to access an application. It is obvious enough that people log in to access something. On the other hand, accessing the app is an important step. You should either tell the whole purpose of the app in few words or just leave it as it is. People will understand what does it mean and why that user needs to go in.

There is an article I wrote recently, concerning creation of a meaningful user story

Make hypothesis, not assumptions

People are bad in assuming things. Developers are even worth in doing so. What happens when people assume different things? Right, they miss expectations, they misunderstand each other and tend to work in different directions.

What happens in your brain when you say a customer? You immediately know that all the most important fact about the a person is that this he or she is looking to make a purchase. Can you distinguish the 32 years old man from a 46 years old lady on your website? If not, why encourage engineers or designers to assume that? They will assume different things most likely.

On the other hand, if you are targeting a particular audience or know your customers from google analytics report, then it makes sense to announce that. It is so much clearer to tell your team that our customers mostly are women from western Europe, age from 25 to 36. Then, just reference this audience as a customer. Validate the information about your audience, not assume.

Nobody wants to submit forms

Indeed, this small section is probably the one I agree with. so that I can submit a form is terrible because of the reasons in the article. However, it is completely irrelevant to the call for building empathy.

The purpose of the user story is to facilitate a conversation

Yes, that’s right. The goal of the story is to initiate a discussion between a team and a product owner. It is a way of switching from writing requirements to talking about them. As the author suggests, implementation details aren’t supposed to be there which is correct. The team will figure them out.

Asking questions about the user performing the task doesn’t deserve that much focus as it described in the article. Imagine how long would it take to discuss every way that Joe can live his life and interact with the login form.

Although, the writing of requirement is still quite important when you try to communicate them!

You never know what actual people think about

Staying away from technical details in the user story is good advice. However, suggesting to focus on actual people’s though instead is a little bit a trick. These two statements are not connected at all. You do have to do anything instead. Just do the first part - remove implementation details. That’s it. Don’t try to guess. Guesses are bad for you.

There are way more questions could be asked about the story, and the good one will deem unimportant ones and put the most vital into the focus. It is what the Scrum approach is all about.

We will notify you about new posts every few weeks