Skip to end of metadata
Go to start of metadata

An agile way to express requirements.

User story definitions from various sources

Wikipedia
extremeprogramming.org
Agile Modelling

User story template

Source: Dan North

Title (one line describing the story)

Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title
Given [context]
  And [some more context]...
When  [event]
Then  [outcome]
  And [another outcome]...

Scenario 2: ...

Examples

  • As a customer, I want to calculate the prices of a car insurance online, so I can figure out which insurance I want to buy.
  • As an IT-techie, I want to run the solution seamlessly on a cluster, so I can deliver high uptime (as specified in the Service Level Agreement).
  • As customer-support, I want the information from the customer merged automatically and correctly into our CRM, so I do not have to do this manually.

Granularity, composites and levels

In general we have two types of user stories regular and epic.

Regular user stories

Regular user stories should adhere to the following

  • Limited size
    • Possible to implement within two weeks is a good rule of thumb, at least within one sprint.
  • Must add business value
  • The so that clause is important so all stakeholders understand the purpose.

Epic user stories

Epic user stories are user stories that have not yet been broken down to regular user stories. They can be put on the backlog, but should never make it into a sprint. They can be used directly for release planning, but are normally only used to ensure that requirements are not forgotten.

  • Don't spend time breaking down an epic user story until it is relevant for the upcoming sprint. Postponing the activity is always a good idea, because you may learn something in the meantime that changes how it should be broken down, if it should be implemented at all, etc.
  • When an epic user story has been broken down into multiple regular user stories, the epic user story is redundant and should be deleted.

Requirement tracking

It is important to have requirement tracing during a systems life cycle to ensure that requirements are not lost. A requirement matrix (or something similar) will make it easier to:
-identify which requirements that are affected by code changes.
-identify which system components we have to change if the requirement is changed
-what do we have to retest if the requirement is changed
Whenever the system requirement is changed, the affected areas in the software life cycle must be kept consistent with the updated requirements.

It should be possible to follow the life of a requirement, in both a forward and backward direction. A single requirement must be able to be traceable during all stages of the production, delivery and installation.

Requirements tracing should capture all levels of requirement engineering. The customer's interests and needs should be applied to the product's goals, constraints, and outcomes. Another important level is the understanding between the customer and the supplier on the functionality, non functionality, and possible side effects of the technical level.

So, how should this tracing (and communication within the project) be performed so all involved parties are notified when a requirement is changed? Consider how the change of the requirement impact the rest of the system? And of course, when a component/functionality is changed has that any impact on the requirements?

Resources

Labels:
agilepracticemust agilepracticemust Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 05, 2008

    • In which form should we express requirements? And why this form?
    • Where do you store the requirements? In a wiki?
    • How do you break down top level requirements to managable sized portions?
    • How do you organize and group requirements?
    1. Sep 11, 2008

      And at last, don´t forget:

      • How do you document and track dependencies between different sets of requirements spread across different level in a project/product requirement hierarchy, between different project/products and along the lice cycle og the projects/products... Typical examples from the enterprise domain are Business Rules coupled to key Business Objects which again is present in many systems and projects...
      1. Sep 11, 2008

        I'm on it. Writing down some notes now, stay tuned for more elaborate descriptions.

        See Mapping between requirements and tests and Upstream-downstream relationship applied to User Stories.

  2. Sep 05, 2008

    • Link to preferred resources. DO NOT duplicate descriptions found in other sources. The purpose of this page is not explain the concept of user stories, but serve as a foundation for further