Jeff Patton has raised a legitimate issue with the description of User Story as a "requirement". As Jeff points out, XP practitioners see a story as a "promise for a conversation".
- Seconding this notion, also as it pertains to the "Limitation" defined that a User Story is a "conversation starter". Per my understanding, that is exactly the intent and, further, conversation is essential in the context of the Agile Manifesto. Trobbs (talk) 17:46, 1 September 2011 (UTC)
Also look at Dan North's very useful guide to story content from Behaviour Driven Development.
Why is there no reference to Mike Cohn's work with User Stories? Many Agile software development practitioners acknowledge his leadership in this area. His book "User Stories Applied" is arguably the best current reference on the topic. His web site contains further information.
--Peter Hundermark 12:22, 6 July 2007 (UTC)
Other Methodologies and Models
I feel it is important to note that user stories are not limited to Extreme Programming. Other models, including non-Agile models like the Unified Process use user stories. —Preceding unsigned comment added by 184.108.40.206 (talk) 18:38, 25 April 2008 (UTC)
- There is a difference between User Story and Use Case, you know? 220.127.116.11 (talk) 06:18, 12 September 2012 (UTC)
Format of User Stories
Posted by Mike West:
I agree that the significant work of Mike Cohn should be recognised. Additionally, I do not believe the examples given are exemplary. The point of a user story is to identify the user role and the requirement associated with the role. For example, a properly written user story might be:
"As the editor of a document I want the most recent document I have been working on to open when the application starts up."
"As the user, I want to be prompted to save any changes I have made when closing the application."
- NOTE: This format is not the only way to write a user story. This format actually came from Connextra, and was dropped after they'd solved their problem. See http://blog.gdinwiddie.com/2012/01/23/contemplating-given-when-then/#comment-143732 - George Dinwiddie — Preceding unsigned comment added by 18.104.22.168 (talk) 20:22, 4 March 2013 (UTC)
- I think that for many design tasks, these examples make too many assumptions. If you're designing the UX component of the system, these are specific solutions, whereas the user stories should only describe the problem. It should not make any assumptions about the software to be built (or even that such software will be built) and it should be written in the users' language. I would prefer the following if I were doing the design:
- "As an author, I will want to work on the same few documents over many working days, and be able to return to it quickly."
- "As an author, I do not want to risk losing work."
- For the first, the designer can choose to open with the most recent document, or with a list of recent documents. For the second, the designer can choose to prompt to save, to use an auto-save feature, or to have auto-recovery. The point is to map out the problem without limiting yourself to a single solution.
Disambiguation: User story, Use case and Scenario
See the discussion there: Talk:Use case#Disambiguation: User story, Use case and Scenario, please. Franta Oashi (talk) 23:07, 8 July 2009 (UTC)
- Personally I wonder why the page needs a table comparing Use Case and user Stories. They are only vaguely related. The definitions in the wiki pages should provide sufficient info to understand the difference. Do they? Craigwbrown (talk) 15:00, 29 January 2012 (UTC)
Best definition of a User Story
Charles says: I'm sorry but I do not know the first thing about how to successfully change a wiki page, or how to cite references, the proper format of postings, etc.
However, I'd like to point out that I think the definition/description of a user story here on wiki places way too much emphasis on the sentence and way too little on the other two critical components of a user story(conversations, tests).
_User Stories Applied_ by Cohn (p.4)
"...A user story describes functionality that be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects:
- a written description of the story used for planning and as a reminder
- conversations about the story that serve to flesh out the details of the story
- tests that convey and document details and that can be used to determine when a story is complete..."
This 3 component definition is further backed up here, by one of the main authorities on Extreme Programming: http://xprogramming.com/articles/expcardconversationconfirmation/
I would like someone else make the changes to reflect this, or if anyone would be willing to help me make this change to the page by corresponding with me via chat or email, I'd appreciate it.
You can contact me at 'chuck-lists2' at 'emailchuck' dot com
the current text is simply not true. Michael Cohn author of User Stories Applied write in his blog how function requirements can be handles satisfactorily | http://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories/
Specific changes - example
I wrote up a draft page to test a better way of describing a User Story. It's not perfect and culd use yoru help. It is here. If you can use it, or improve on it to help this page out, please do.Craigwbrown (talk) 15:02, 29 January 2012 (UTC)
- What is a User Story
- Origins (XP, but also earlier work on narratives and story telling?)
- Card, Conversation, Confirmation
- Common Form User Story
- * As a, I want, So that explained
- * 2-3 examples
- * Rationale for format
- * Challenge to format
- Related topics
- * BDD
- * Product Backlog
- * Story Maps
- * Kanban
- * c2 wiki
- * ExtremeProgramming.com
- * Mike Cohn
- * others
Limitations to scope
I feel this topic should be limited to the above structure and topics such as BDD, INVEST, Story Maps etc should all be referenced in a Related Topics section. Craigwbrown (talk) 14:53, 29 January 2012 (UTC)