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.

Traditional requirements engineering tries to describe a system as complete and consistent as possible. Completeness in this sense means that all functionality must be described but the description's depth will vary depending on the specification's purpose. Consistency means that any two requirements must not be contradictory at any time in the requirements process. The 'at-any-time' constraint is important to develop the differences between use cases and user stories.

Thesis 1: Period of consistency

A user story - as used in agile processes - must be consistent with the other user stories at the time of it's implementation. A use case - as used in traditional requirements engineering - must be consistent with the other use cases at any time.

This is perfectly understandable if you take into consideration one of the central principles of the agile world: do what is important now - postpone the other stuff.
So a user story's purpose is to describe a system's (functional) aspect at the time of implementation. It is however not usable as an all-time requirement description. One sprint later the user story might already be inaccurate if not obsolete at all.

Consequence 1: Time eats consistency

The set of user stories that an agile team produces is inappropriate for describing a system's behavior past the end of the project's lifetime.

If you need requirements documentation for maintenance user stories are insufficient. You still need something like a software requirements specification.