Another post in favor of another User Story format
Some time ago I wrote a post supporting the idea of a new template for the User Story. In that post I tried to explain why we should bring the "value" (because) clause to the fore, to make it the most important clause of the User Story template.
Then John Arrowwood commented on that post and made a reasonable argument to stick to the "old" (or traditional) format for User Stories.
This is a second post in defense of the new template, where I try to explain why the "value" clause in the user story should be brought to the fore, to be the most important clause in the User Story. Here's the template I propose:
Although I don't see any logical flaw in John's argument I don't agree with it. The reason is that in reality I don't see that people understand the ultimate goal of the User Story which is to justify every functionality in terms of what value it brings to the user.
No matter how much we stress the need to have the "value" properly described I don't see anyone (literally) using it. Normally the User Story writer will not understand the real "value" for the user before I do the 5 why analysis on the "feature" so that the person understands the deep reason why that "feature" is valuable to the user.
I also see that people don't spend anytime writing the "value" part of the clause, they tend to use banalities and obvious things. Writing an obvious "value"-clause delivers zero value when communicating the user story. Remember that it is the "unexpected" and "non-obvious" that actually delivers value, because it contains information that was not obvious to the reader.
Here's an example: everybody knows that as a user of Yahoo! e-mail client I want to save emails sent and received because I may want to return to some business-critical information later on, what not everybody knows is that as a Gmail user I prefer not to have a folder structure to archive old e-mails because it's easier to search than to create a folder system for archiving.
If you take as value the "archiving" then you will create a stupid folder structure for people to be able to "store" old e-mails. However if you take the "finding easily a relevant e-mail" as the value people are looking for, you may start to think twice and ask yourself if all users (all over the globe) are really librarians that think in archive-system terms. Guess not.
When you write a User Story start from the value. Always. No Exception. Ever. Start by asking yourself what does the user/customer really want to do. I mean really! (hint: seldom customers are happy with just using your product, they normally want to accomplish something!)
The value part of the User Story should be the non-obvious part of that value, the obvious explanation for a User Story does not deliver any information to the person downstream that will read the story and have to implement it.
I don't expect everybody to understand this, then again I don't expect all companies to create great products.
Learning to be better is not mandatory. Then again, neither is survival...
at
21:27
Then John Arrowwood commented on that post and made a reasonable argument to stick to the "old" (or traditional) format for User Stories.
This is a second post in defense of the new template, where I try to explain why the "value" clause in the user story should be brought to the fore, to be the most important clause in the User Story. Here's the template I propose:
- In order to "benefit/why/value"
- As a "user role"
- I want "feature/functionality"
Although I don't see any logical flaw in John's argument I don't agree with it. The reason is that in reality I don't see that people understand the ultimate goal of the User Story which is to justify every functionality in terms of what value it brings to the user.
No matter how much we stress the need to have the "value" properly described I don't see anyone (literally) using it. Normally the User Story writer will not understand the real "value" for the user before I do the 5 why analysis on the "feature" so that the person understands the deep reason why that "feature" is valuable to the user.
I also see that people don't spend anytime writing the "value" part of the clause, they tend to use banalities and obvious things. Writing an obvious "value"-clause delivers zero value when communicating the user story. Remember that it is the "unexpected" and "non-obvious" that actually delivers value, because it contains information that was not obvious to the reader.
Here's an example: everybody knows that as a user of Yahoo! e-mail client I want to save emails sent and received because I may want to return to some business-critical information later on, what not everybody knows is that as a Gmail user I prefer not to have a folder structure to archive old e-mails because it's easier to search than to create a folder system for archiving.
If you take as value the "archiving" then you will create a stupid folder structure for people to be able to "store" old e-mails. However if you take the "finding easily a relevant e-mail" as the value people are looking for, you may start to think twice and ask yourself if all users (all over the globe) are really librarians that think in archive-system terms. Guess not.
When you write a User Story start from the value. Always. No Exception. Ever. Start by asking yourself what does the user/customer really want to do. I mean really! (hint: seldom customers are happy with just using your product, they normally want to accomplish something!)
The value part of the User Story should be the non-obvious part of that value, the obvious explanation for a User Story does not deliver any information to the person downstream that will read the story and have to implement it.
I don't expect everybody to understand this, then again I don't expect all companies to create great products.
Learning to be better is not mandatory. Then again, neither is survival...
Labels: agile, customer, format, lean, product design, requirements, user stories, value
RSS link
3 Comments:
So, have you implemented this on any projects? Does it help?
It seems to me that this is really a band-aid to address a larger problem: Unqualified and/or uneducated people trying to write user stories, and they can't seem to follow directions. I have my doubts that making this change would actually make a difference if these are the kinds of people writing the user stories.
In some respects, it would be nice to have two different versions of a story: One for the business people that are focused on value, for prioritization purposes, and another for the developers, who are focused (at least on a day-to-day basis) on the task at hand of building the product. But that is just one way to solve the problem. Feature groups, epics, there are lots of ways of addressing the 'value' issue for the sake of prioritization.
Personally, what I think is needed is for someone to be involved in the creation of the story cards that won't let people get away with not doing it right. That's part of the reason I advocate true Quality Assurance instead of just 'testing.' Involve some PITA such as myself throughout all phases of the project, and not just at the end. But I bet you can guess how often that actually happens.
By
John Arrowwood, at August 12, 2009 1:16 AM
@John
The proposal is not a band-aid to address unqualified people :)
I've seen many qualified people "drop" the "so that" clause in the original format because it's easier and "everyone knows" what the story is about.
The new format suggestion is about making the goal of the User Story format even more obvious!
And to answer your question, I've not used this in any software development project. There seems to be some resistance to changing "existing" formats :)
By
Unknown, at August 12, 2009 12:26 PM
The goal of this is to get people to write good user stories, correct?
Problem I see is that you want people to think about it before they write it, and a template does the opposite.
What I think is needed is more of a questionnaire or something. As a series of questions which can be condensed down into a user story when you are done. I have tried to create such a thing, but am not quite satisfied with it, yet. If you create one, let me know.
By
John Arrowwood, at November 03, 2009 2:50 AM
Post a Comment
<< Home