Difference between revisions of "User story"

From CNM Wiki
Jump to: navigation, search
Line 1: Line 1:
A [[user story]] (plural: [[user stori]]es; hereinafter, the ''Story'') is the brief description of a [[requirement]] to a desired system that is written from this system [[customer]]'s or [[end-user]]'s point of view. In other words, the ''Story'' is a high-level, informal, brief, non-technical description of a solution capability that provides value to its [[stakeholder]]. The ''Story'' is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it.
+
A [[user story]] (plural: [[user stori]]es; hereinafter, the ''Story'') is the brief description of a [[solution requirement]] to a desired system that is written from the point of view of the [[customer]] or [[end-user]] of this system. In other words, the ''Story'' is a high-level, informal, brief, non-technical description of a solution capability that provides value to its [[stakeholder]]. The ''Story'' is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it.
  
  

Revision as of 00:29, 26 February 2020

A user story (plural: user stories; hereinafter, the Story) is the brief description of a solution requirement to a desired system that is written from the point of view of the customer or end-user of this system. In other words, the Story is a high-level, informal, brief, non-technical description of a solution capability that provides value to its stakeholder. The Story is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it.


Format

Either the product owner or the team writes the Stories according to the following structure:

As a [type of user], I want to [perform some task or execute some function], so I can [achieve some goal].

Related concepts

  • Product epic (epic story, epic). A large user story that, in its current state, would be difficult to estimate or to complete in a single iteration. Epic stories are typically lower priority and are waiting be broken down into smaller components.
  • Story mapping. refers to a top-down visualization, or roadmap, of product backlog. The story map starts with a goal or specific functionality, which is then broken down into user stories. A story map is created in tree format either physically, using post-its on a wall, or digitally.
  • Story point. A measurement used by Scrum teams to determine how much effort is required to achieve a goal. In other words, a story point is a non-unit measure used to determine the complexity of the Story. Story points are relative, not absolute, and do not relate to actual hours. They can be anything from Agile T-shirt sizes to the Fibonacci sequence.
  • Storyboard. A tool inspired by the filmmaking industry, where a visual sequence of events is used to capture a user’s interactions with a product. Depending on the audience, it may be an extremely rough sketch, purely for crystallising your own ideas.
  • User persona. (1) A fictitious identity that reflects one of the user groups for whom the product is being designed; (2) A detailed hypothetical description or biography of a typical end-user who will be using the product. User personas usually take the form of a written document, complete with stock photo, name, profession, style of living, and other details pertinent to their being categorized as an end-user.
  • Spike. A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the Story.

Related lectures