Mittwoch, 11. August 2010

The user story's anatomy

Unfortunately there are different meanings for the term 'user story'.

The following items are usually called 'user stories':
  • A well-structured sentence like 'as a blog author I want to be able to upload images in order to impress my readers'
  • A card containing a well-structured sentence (like the above), enriched with user acceptance criteria and constraints
  • The above card, plus some collaboration
  • All of the above and additionally an estimate and a priority (aka backlog item)

The common denominator is that the usual scheme...
As a {role} i want to {ability} [in order to {purpose}].
...is called a user story.

A user story's scope is always to define some functional requirement, in some cases bounded by non-functional constraints. This is a major weakness in all agile processes, as the non-functional requirements - which drive the architecture and the system's cost - don't get enough consideration.


A user story card is a composition of...
  1. A story (functional requirement, 'as a ... i want to ... in order to ...)
  2. One or more user acceptance criteria
  3. One or more constraints (non-functional requirements)
Depending on the user story's degree of maturity the user acceptance criteria or the constraints can be omitted. And of course the story's maturity will be driven by it's temporal proximity to the project's current sprint.

Dienstag, 3. August 2010

User Stories Revisited

Today I had a very inspiring discussion with Peter Hruschka from The Atlantic Systems Guild regarding the differences between the traditional requirements engineering artifacts...
  • use cases
  • atomic requirements
and the agile world's ...
  • user stories
Both are used to describe a system's requirements, albeit they are adressing different purposes.