User Story Discussion

I read all the various comments about user stories and sense there is a serious lack of consensus regarding just what a UserStory is. English speakers typically think of a story as some kind of narrative that describes a WHO, WHAT, and WHY scenario. So, from that perspective, it is doubtful to me that a story is going to be at the brief, functional level a programmer needs to develop code.

Therefore, I suggest that the USER STORY is indeed a narrative that a user tells from her own perspective. This story typically describes some kind of scenario or situation that the user finds herself in. The programmers must then work with the user to derive from that narrative the specific USER TASKS that the user must to perform with the software to successfully accomplish the story.

For example, here is a real USER STORY:

: A project manager needs to set up a web-based location where all the members of her team can access engineering drawings, models, research findings, meeting minutes, and schedules associated with their latest project. This will help the team stay in synch regarding the progress of the project. It will also prevent the current problem of storing data in different places that not everyone can access.

And here are USER TASKS we derive from the story:

Create a project on the web.
Create folders in the project.
Transfer files to those folders.

And if the user makes any mistakes regarding the name or location of a project, folder, or file, she must be able to:

Rename a project, folder, or file.
Move a folder or file.
Delete a project, folder, or file.

I think you can see that it is the user TASKS, NOT the STORY, that represent those chunks of functionality that can be estimated, prioritized, and then implemented by the software programmers.

What is your take on this Kent? Is there anyone else out there who is comfortable with this concept of User Story and User Tasks?

-- Martha Roden, Usability Engineer and Interaction Designer

What you have above are all sensible things to say, but they aren't a capital-S Story. A capital-S Story is:

Testable -- You can write automatic tests to detect the presence of the story.
Progress -- The customers side of the team is willing to accept the story as a sign of progress toward their larger goal.
Bite-sized -- The story should be completable within the iteration.
Estimable -- The technical side of the team must be able to guess how much of the team's time the story will require to get working.

As iterations have gotten shorter (I always start with one week) and teams have gotten smaller, the scope of a single story has shrunk. I certainly feel the need for larger-scale structuring mechanisms. Some folks use "theme", others "big story" or "initiative".

Re: the details above. What is missing from this is "why". Why does the user want to do this. Story writing should be an opportunity for the customers to reflect on and refine their craft.

Kent

I like the idea of the "User Tasks", though in practice, many users (and developers) might initially frame some as "System Tasks". For example: "Require entry of a userID." versus "Enter UserID." I've been casting some user stories as use case scenarios, so my "User Tasks" end up being called "Scenario Steps".

Huet Landry

I am following this discussion on User Stories. But at this time I am a bit confused and want to see a UserStoryAndUseCaseComparison. For example, do we only document the success scenarios in a user story or do we also cater for failure scenarios or alternate flows as in use case? Without documenting the success and failure scenarios both, how can we get a complete picture of the work for the unit and therefore how can we write tests and estimate them?

Please give me some information on how to write user stories and what exactly to include in them?

Thanks

Samudra Gupta

Thanks a ton for that link on user stories and use cases comparison. One more thing I want to know is the use of coloured cards with extreme programming and agile methods. Any pointer on that please? I am seriously embarking on this on my next project.

Thanks

Samudra Gupta

In ExtremeOpenBusiness, a UserStory is given by making all UserInteractions? with the real market transparent, inspired by DaveBrin?s TheTransparentSociety. By transparently collaborating with OpenSource programmers (this is much more than "only" restricting programming to piecewise open releases of software sources to the public), the programmers get their real time-input from the users: e.g. EOB users, who practise SocialDomaining, by exposing their domain portfolios, as public Google Spreadsheets or EditGrid? Spreadsheets, via wiki pages. The users describe their needs on these wiki pages, e.g. we want a pay button in each row, that lets pop up a dialogue window, which initiates a transaction of domains and funds.

the Buyer inputs the addresses of their open domain portfolio and their e.g. paypal account.
A funds transfer is initiated from buyer to seller.
The source and target domain portefolios are adapted accordingly.
DomainRegistrarTransfer? is initiated.

In a human dialogue, the wants are refined until everything is crystal clear to the programmers. In this open process now, some users want e.g. to have attached to the spreadsheet a MakeOffersList?, which for XP-programmers takes a matter of minutes to code this additional feature. Now some users want to pose this list into a domaining forum, say NamePros?, where there is an established community, who trade domains on an internal currency. As all these user-actions are already occurring real-world transactions, these transactions tell the story. These sketchy remarks can be refined in the public. The author leaves a backup of his conceptual input on the following WikiTrailmark (http://trailfire.com/fridemar/marks/224077). -- FridemarPache

CategoryDiscussion