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 box
Should be a password box
Should be a change password link
Should be a remember me link
Should 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]

There is a pretty good write up of this on Dan North's site, so to save me repeating it, check his page out, he also steps into BDD style stories too, and how they reflect various scenarios.

 

 


Posted 09-17-2008 12:55 PM by Jak Charlton

[Advertisement]

Comments

Derik Whittaker wrote re: Don't Tell Me "How", Tell me "What"
on 09-17-2008 8:27 AM

When you told him (assuming him) this, how did he react?  Did he understand where you were coming from?

Casey wrote re: Don't Tell Me "How", Tell me "What"
on 09-17-2008 8:44 AM

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...

Casey wrote re: Don't Tell Me "How", Tell me "What"
on 09-17-2008 9:20 AM

Jerry did originally suggest I put a comment on his behalf :

"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...."

Not too far from the mark ... and wonderfully modest!

Dew Drop - September 17, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - September 17, 2008 | Alvin Ashcraft's Morning Dew
on 09-17-2008 9:27 AM

Pingback from  Dew Drop - September 17, 2008 | Alvin Ashcraft's Morning Dew

Arjan`s World » LINKBLOG for September 18, 2008 wrote Arjan`s World » LINKBLOG for September 18, 2008
on 09-18-2008 4:35 PM

Pingback from  Arjan`s World    » LINKBLOG for September 18, 2008

Caligula wrote re: Don't Tell Me "How", Tell me "What"
on 09-21-2008 12:25 PM

My user stories tend to be much less verbose:

> 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 :(

Bob Saggett wrote re: Don't Tell Me "How", Tell me "What"
on 09-21-2008 12:45 PM

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?

Caligula wrote re: Don't Tell Me "How", Tell me "What"
on 09-21-2008 6:24 PM

@Bob User stories don't exist in isolation.

gOODiDEA.NET wrote Interesting Finds: 2008.09.15~2008.09.21
on 09-21-2008 6:47 PM

Other Don't Tell Me "How", Tell me "What" Microsoft Network Monitor 3.2 .NET MSDN

gOODiDEA wrote Interesting Finds: 2008.09.15~2008.09.21
on 09-21-2008 6:48 PM

OtherDon'tTellMe

Technical descions with managers « simple wrote Technical descions with managers « simple
on 09-22-2008 4:17 AM

Pingback from  Technical descions with managers « simple

Bob Saggett wrote re: Don't Tell Me "How", Tell me "What"
on 09-22-2008 5:47 AM

@Caligula

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.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)