How to work with requirements and testing in Agile projects

The IT industry is a young industry and we have seen huge evolvements over the past couple of decades. In the past it was important to ‘do it right from the beginning’. In some sectors and industries this still applies – to start over when building a house or a bridge that was started off and built wrong is very costly. In IT, however, matters are different and things change fast, extremely fast in fact. Keeping up with changes is a challenge in and of itself. Even Darwin realized that it is not the strongest nor the smartest species that survive; it is the ones that are best able to adapt to change.

So how does this talk of evolution fit in with requirements and testing in Agile projects?

In the beginning, the requirements were very limited. In this century’s first decade, there were many who tried to write very detailed requirements, for example, use cases with step by step descriptions of what would happen in different situations.

Nowadays the pendulum has swung back and agile development is commonly attributed to limited requirements, often written by a requirements manager belonging to the business side of the company. Of course, in order for high level requirements to work, a close collaboration between the writer of requirements (the client) and the one to create something based on the requirements (the supplier) is needed. If these two parties don’t understand each other clearly, no magic is bound to happen.

How should you document requirements in an Agile project?

There are many ways to document requirements in an Agile project, and many of these work equally well. The most important thing when documenting requirements is not the form the requirements take, but that it is done and that the communication within the team works.

Requirements can amongst others be in the form of user stories, use cases, normal text, sketches or prototypes.

It is less efficient to write requirements that are heavily detailed before anything is built based on them. It will be become like Chinese whispers in that what the user originally wanted and intended is rarely, if ever, delivered. Don’t allow requirements to be detailed too much by too many participants.

How should you deal with obvious requirements?

In order to be able to ride a bike the wheels have to be round. An accounting system must be able to deal with VAT. Through frequent discussions and usability testing on real users obvious mistakes of this type can be avoided. Of course, having the right people in the project is just as important.

Read more about obvious requirements here – 7 Requirements you should never overlook Part 1 and 7 Requirements you should never overlook Part 2

In traditional development many activities are conducted in series. Only when a task is completed can the next activity begin.

In agile development we strive to parallelize tasks. Requirements management is not a single activity at the beginning of the project, it is spread out over the development period.

Testing starts as soon as there is something to test; it’s not an activity that is performed when the development is completed.

In conclusion, the focus on requirements and testing has moved with Agile development. It is no longer so important that requirements are complete before coding. The requirements may very well be ready after the tests have been performed. The purpose of testing is no longer principally to find defects, it is just as much to provide valuable feedback to the development team.

NEXT – Read all about writing good test cases to lower costs and lighten work loads.