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.