Agile Glossary -User stories

What are user stories?

In examination with the product owner or the costumer , the team subdivide up the work to be done into functional increments called “user stories.”

Each one of them is expected to return, once implemented, a contribution to the value of the overall product(irrespective of the order of implementation) these and other assumptions are captured by the INVEST formula.

To make these assumptions perceptible, user stories are exemplified into a physical form: an index card or sticky note, on which a short descriptive sentence is written to serve as a indication of its value.

This emphasizes the “atomic” nature of user stories and encourages direct physical manipulation: for instance, decisions about scheduling are made by physically moving around these “story cards“.

Common Pitfalls

a basic mistake that teams where the Agile approach is established, to the development team or adopted after a non-Agile requirements phase, is to start from a requirements document in narrative format and derive user stories directly based on its structure: for example, one story for each section of the document.
as the 3 c’s model emphasizes: a user story is not a document; the term envelop all of the knowledge required to transform a version V of the product into version V’ which is more valuable with respect to a particular goal.
the level of detail corresponding to a user story is not consistent, it evolves over time as a function of the “planning horizon”; for example, a user story which is scheduled for the next iteration should be better understood than one which will not be implemented until the next release.
a user story is not a Use Case; Even if it is useful to compare and contrast the two, they are not equivalent and do not admit a one-to-one mapping.
a user story does not in general correspond to a technical or user interface component: even though it may sometimes be a useful shortcut to talk about e.g. “the search dialog story”, screens, dialog boxes and buttons are not user stories

Expected Benefits

For most Agile teams user stories are the main vehicle of incremental software delivery, and offer the following benefits:

moderate the risks of delayed feedback
if the increments are small
if the software is released to production frequently
the option to change the mind of the customer or product owner, on the details or the schedule priority of any user story not implemented yet.
for developers, being given clear and precise acceptance criteria, and ongoing feedback as they complete work.
promoting a clear separation of responsibilities between defining the “what” (dependency of the customer or product owner) and the “how” (province of the technical team), leveraging the skills and creativity of each.

Potential Costs

Incremental development in general, and the “nano-incremental” strategy incorporate in user stories has significant impacts on projects’ testing strategies, but mandate significant test automation.

But that’s what causes the problem : after implementation of feature F1 it is normal to test that feature. After implementation of feature F2, the risk of regression dictates re-testing F1 as well as testing F2. A test sequence assuming incremental development therefore goes: F1,F1+F2,F1+F2+F3, etc. – this grows as the square of the number of features, and can therefore quickly become unmanageable as projects grow in size. Test automation pacify this effect, although it does come at a cost.

Origins

User Stories originate with Extreme Programming (XP) their first written description in 1998 only claims that customers define project scope “with user stories, which are like use cases”. Rather than offered as a distinct practice, they are described as one of the “game pieces” used in the “planning game”.

Signs Of Use

the team uses visual planning tools (like story map or task board) and index cards on these displays to match features of the product.
the labels on cards that stand for user stories contain a few (or no references) to technical elements (“database”, “screen” or “dialog”) but generally refer to end users’ goals.

Skill Levels

As an individual contributor:

Beginner

able to start from another form for requirements (narrative document, use cases) and transmit that to user stores.
knows at least one standard format for expressing user stories.
able to illustrate a user story with an example (including user’s goal, existing context, user’s actions and expected outcomes).

Intermediate

able to divide up the functional goals of a development effort into user stories ensuring no gaps are left.
knows several formats for expressing user stories and can choose the most appropriate.
able to express the acceptance criteria for a user story in terms that will be directly usable as an automated acceptance test.
knows or can identify the relevant user roles and populations(and refers to them appropriately in user stories).
can assess a user story using the INVEST checklist or an equivalent, and rephrase the user story as necessary.

Advanced

able to interpret so-called “non functional requirements” in terms of user stories.
able to link user stories to higher level descriptions of project goals and to provide grounds for the relevance and business value of each user story.

Collectively, as a team: