Talk:User story

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Mid-importance).

Comments

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^[1] and, further, conversation is essential in the context of the Agile Manifesto^[2]. Trobbs (talk) 17:46, 1 September 2011 (UTC)[reply]

See The eXtreme Programming description of a story

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)[reply]

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 205.210.232.62 (talk) 18:38, 25 April 2008 (UTC)[reply]

There is a difference between User Story and Use Case, you know? 95.89.134.68 (talk) 06:18, 12 September 2012 (UTC)[reply]

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

Or:

"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 66.87.7.213 (talk) 20:22, 4 March 2013 (UTC)[reply]

165.228.109.94 (talk) 07:04, 8 October 2008 (UTC)Mike West165.228.109.94 (talk) 07:04, 8 October 2008 (UTC)[reply]

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

and

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

145.18.213.159 (talk) 15:35, 12 November 2012 (UTC)[reply]

5 W's

I think the 5 W's example is wrong and should be:

As <who> <when> <where>, I want <what> because <why>

However I recognise that it is 'wrong' in the source. FreeFlow99 (talk) 16:18, 16 March 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)

Definition:

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

Charles B Qqchuck (talk) 20:11, 6 January 2011 (UTC)[reply]

References

^ Jeffries, Ron. "Essential XP: Card, Conversation, Confirmation".
^ "Manifesto for Agile Software Development".

Functional requirements

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/

Streamdreams (talk) 13:58, 20 May 2014 (UTC)[reply]

Suggestions

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)[reply]

What is the Enter Expenses example doing here? It is not an example of a user story - is reads more like a traditional SRS. — Preceding unsigned comment added by 87.114.164.17 (talk) 09:41, 17 May 2015 (UTC)[reply]

Structural changes

Here is a proposed list of new headings to manage the content. Let me know what you think Craigwbrown (talk) 14:53, 29 January 2012 (UTC)[reply]

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

References

* 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)[reply]

Wholesale reuse of Agile Alliance's Guide

The "History" section (and possibly other WP material on Agile) seems to me to fall afoul of WP's own rules regarding proper attribution of material lifted from other sources.

It is copied in entirety and word-for-word from two Guide entries: http://guide.agilealliance.org/guide/user-stories.html and http://guide.agilealliance.org/guide/threecs.html.

(This is what https://wiki.riteme.site/wiki/Wikipedia:Plagiarism describes as "No in-text attribution, no quotation marks, no change in text, inline citation only", constituting plagiarism.)

As the author, I'm mildly flattered. But I also feel grumpy at having my work so liberally borrowed with so little attribution. Is there any record of the Agile Alliance, which owns and publishes the work, having granted WP permission for literal reuse of the Guide? — Preceding unsigned comment added by 81.64.218.80 (talk) 16:32, 20 June 2015 (UTC)[reply]

Unreliable sources

Some of these sources don't appear to me to meet reliable source guidelines. Many of them are just blogs, which fail WP:SPS. Martin Fowler is an expert, so this could be used with attribution, but Alex Cowan and Antony Marcano (the two examples I checked) have not been clearly established as such. Examples are the obvious way to write an article like this, but collecting examples from the web will quickly lead to a pile of refspam, so sources need to be handled with caution. Grayfell (talk) 18:02, 29 April 2016 (UTC)[reply]

I reverted revision 895131045 by Walter Görlitz which removed the reference for the explanation of acceptance criteria. I thought the reference was worthwhile since the explanation seemed clear and useful and the source looked independent and reliable, even though, like many sources on this page, it’s a blog. Because acceptance criteria aren’t specifically defined in methodologies like XP or Scrum, it’s hard to find published sources on them (the sources tend to be about physical engineering not software/computing). That said, I’m new to Wikipedia so may have got it wrong. PeterOliverGibson (talk) 03:58, 12 May 2019 (UTC)[reply]

Look at who has published those blogs though. They're generally from recognized individuals, not random bloggers. Walter Görlitz (talk) 14:23, 12 May 2019 (UTC)[reply]

Features, requirements and user stories

Different people have different ideas of what a requirement is... which makes this quite hard to discuss... but I think this article falls in an odd place when it says:

"a user story is an informal, natural language description of one or more features of a software system"
"User stories are often confused with system requirements. A requirement is a formal description of need; a user story is an informal description of a feature."

Many people think that user stories are better than features because they tell us what the user actually wants... i.e. the requirements.

e.g. Mike Cohn, author of many books on agile, in this blog post for his company:

"Extreme programming (XP) introduced the practice of expressing requirements in the form of user stories, short descriptions of functionality–told from the perspective of a user"

The DSDM agile project framework says:

"A User Story is a requirement expressed from the perspective of an end-user goal. User Stories may also be referred to as Epics, Themes or features but all follow the same format."

The second sentence is basically saying that you might need many features (which could be combined into a theme or epic) to meet the requirements given in a user story.

In trying to find something that says that user stories aren't requirements, I found a blog post called User Stories Ain't Requirements that says:

"A user story is a reasonably good approximation-some may argue a substitution-for the functional part of a requirement."

After a brief Google, this is the nearest thing to the view the article currently sets out... but it still some way from that view.

At some point we need to make the article reflect the range of views in the sources. Does anyone want to offer any sources supporting the view currently put forward in the article?

Yaris678 (talk) 18:55, 31 January 2019 (UTC)[reply]

[1] Jeffries, Ron. "Essential XP: Card, Conversation, Confirmation".

[2] "Manifesto for Agile Software Development".

[1]

[2]