Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com

Don't Tell Me "How", Tell me "What"

During a discussion with our project manager earlier today, I used the phrase "Don't tell me how you want it to work, tell me what you want it to do"

We were discussing user stories, and I was trying to get across what I wanted to see on a story card, and what I didn't want to see. He had put a story card on the wall that read:

On the login screen:Should be a username boxShould be a password boxShould be a change password linkShould be a remember me linkShould be a register link

As user stories go, this pretty much sucks as badly as it could. He was trying to tell me how to write a login page, as he saw it, but he wasn't describing what functionality he wanted the accounts system to have.

Don't Tell Me "How", Tell me "What"

My user stories for a similar scenario would be more like:

As a registered user I want to be able to use my existing account details to sign in to the site to allow me to access restricted content

As a registered user I want the site to offer to remember me when I sign in so I don't have to enter my details every visit

As a registered user I want to be able to get a password reminder so that I can login even when I have forgotten my password

As a registered user I want to be able to change my password so that my account is more secure

As a new user I want to be able to register on the site and receive a username and password

None of these say how the user achieves the objectives, but they do encapsulate what functionality is actually required. The first card would have had a developer acting as a parrot and likely producing something that missed the goals widely. The second version allows the developer to see how all these functions will interact, and to make a page that best reflects the requirements ... it also happens that the second set of cards neatly becomes a directly applicable UAT script.

Now we can easily adapt the functionality to new requirements, for example these stories encourage a separation of the view from the actual functionality, so it is more likely we can put a login box on every page, or provide a register by email option instead of filling out a form.

What Format Should Stories Be In?

Traditionally I have tended to go for a simple format:

As a [insert role or type of user here]I want to [insert required fucntionality here]So that [insert business benefit, or desired outcome here]

LOL ... I sent him the link to this post ... perhaps he can post his own thoughts? :)

(failing that I'll give my opinion later ;)

Jerry Schafer
wrote
re: Don't Tell Me "How", Tell me "What"

on 09-17-2008 9:11 AM

I'm the project manager working with Casey. I think the user stories are a great way to compile requirements and explain them in way that's understandable by everyone. The tricky part in this particular project, is to motivate the correct folks to express their requirements (which they believe to have been written out in exhaustive detail months or even years ago) to look at things from this new point of view...

"Yes, the project manager is very accomodating and a wonderful pleasure to work with. I've never seen his equal. I wonder if all Americans are so superbly professional and eloquent? I'm in the wrong country...."

> As a registered user I want to be able to use my existing account details to sign in to the site to allow me to access restricted content

Instead:

Registered users may log in with account info.

(Back of "card")

Users log in with:

- email or username

- password

(And additional story)

Only logged-in users may access restricted content.

> As a registered user I want the site to offer to remember me when I sign in so I don't have to enter my details every visit

Login offers a "remember me" option.

> As a registered user I want to be able to get a password reminder so that I can login even when I have forgotten my password

Login offers password reminder.

> As a registered user I want to be able to change my password so that my account is more secure

Users may change password.

> As a new user I want to be able to register on the site and receive a username and password

Users may register.

The motivations and implementation details are story "metadata" and belong in either the implementation or in ancillary materials, not in the story itself. (IMO, of course.) One place I work uses BDUF; I write stories that point both to my internal, development documenation (wiki) and requirements documentation section (MS Word :(

I hate this type of reaction to specifications. It assumes that the individual developer always knows best about how something should be implemented and smacks of the technical prima donna.

I obviously can't comment on this exact situation. However, in my experience you can get into severe difficulties when user stories are taken by a large team of developers and each implements in their own way. On large projects the end result can seem much more disjointed than when a small team of designers and architects do the design work and give a detailed description of what is required in a module.

Remember that with UI things need to flow, unlike the internal implementation of classes. If the customer says I want a login box, a password box, etc then what is wrong with providing this? Especially if, when you don't, the company does not get paid. Of course, the developers generally don't have to deal with the money collection aspects of the business.

Perhaps I am ranting but I am fed up of reading about how the developers always know best (and I am a developer). If that is the case, why aren't they the ones getting the highest pay?

No, I appreciate that. However, the point of this article, and many arguments I have heard, is about allowing the developer to control the design. The point of my comment is that this is not always (in my experience seldom) a good idea.

Erik Lindblad
wrote
re: Don't Tell Me "How", Tell me "What"

on 09-22-2008 4:36 PM

@Bob

The user stories say nothing about the view design of the application, which is probably what the customer is refering to with his/her specific requests.

The function of user stories are to be a common ground on which developers, customers, designers, share holders and everyone else interested in a project can discuss on equal terms.

When everyone (sort of) agrees on "what" the application should do, it is easier for the developers, designers and everyone else involved to move forward with their respective responsibilities. If done right this has no negative impact on the overall "sense of flow" or "uniformness" of the application.