Using Agile in Traditional Requirements – User stories

An edit of this article originally appeared on Konsultbolag1

Agile methods are often described as if they were from a completely different world when compared to traditional development. However, a great many techniques used in agile development actually do work very well when applied to what is usually called ‘traditional requirements management and testing’.

One of the techniques that can be transplanted from Agile to traditional work is that of User Stories, which you can use in traditional system maintenance as well as when you’re developing new systems.

Use User stories as the basis for both requirements and testing

We’ve talked about using user stories a fair bit already, so feel free to catch up with us here.

A typical problem in traditional development is the scope of the requirements. There are certainly cases where people provide insufficient requirements, but all too often, it’s at least as common and problematic to see requirement documentation that’s too comprehensive.

When there’s too little documentation, it’s difficult to be certain what is to be delivered and tested. If on the other hand, there’s too much documentation, the reader will get bogged down in the details. It’s also harder to manage changes if a large amount of documentation needs to be updated every time, which also increases maintenance costs.

Your goal should be documentation that’s sufficient for its purpose — that way, you avoid overdoing the documentation.

In agile methodology, requirements are often documented in the form of user stories, where high-level requirements are often just one or a few lines long. Every user story is broken down into details and is complemented by test cases. The dialogue between the developer and the stakeholder is documented. User stories in combination with test cases and the dialogue constitute a solid foundation for the developer’s work.

Another great advantage with user stories is that they are written according to a template that forces the author to explain for whom the requirements are made, and why they need to be followed. This is often lacking in requirements in traditional development, where all too often, you just describe what needs to be done, not why or for whom it needs to be done.

User stories are often documented according to template like this:

As a [role] I want to [goal] so that [reason].

Example of a user story:

As a project manager, I want to see the status of all development tasks, so that I can determine whether the project will be finished on time.

Example of a test case for this user story:

A list over all assignments and tasks, including status. It should be possible to sort by all the columns in the list.

So what have we learnt? Do write user stories and then detail the requirements in the form of test cases. It’s a simple, effective and efficient technique that brings a little Agile home even to your traditional work.

Next up – read all about Requirements Management in Agile Projects