Requirements Management in Agile Projects

The effects on the tester’s role which result from taking an agile approach are well established. We have previously talked of the general differences between the two as well as the differences in test documentation.

Just because you’re used to working in a more traditional approach and Agile projects operate differently does not mean you’re irrelevant. This is especially so when we consider requirements management in Agile projects.

When working traditionally it is common that many of the requirements are written at the beginning of the project. All too often, this approach works badly because you can not think of everything at once. As the product evolves, you learn more about what is needed and new requirements arise, while other requirements will disappear.

Agile Requirements Management:

In agile work, requirements are developed throughout the project. Often a product roadmap that describes what is to be done during the year at a very general level is used.

A few weeks before a new sprint is started, the product owner selects the requirements to be implemented in the sprint and these requirements get documented in enough detail so that it becomes possible to implement them.

This approach is called ‘just in time commitment’ and essentially means that documentation should not be developed until it is really needed. The requirements are growing, hence the course of development.

It is important that testers are involved in gathering and documenting of requirements. Testers often add a lot of value in these discussions and the result is that the requirements will be of better quality. Requirements elicitation can be made using discussions and workshops with customers.

Testers should also be involved in reviewing the requirements as part of test planning. Doing so provides an excellent opportunity to ensure that requirements are testable early on.

Since testers are involved in much more than just testing, they will easily be able to participate in design discussions and through their input the product will contain less errors. Additionally, the testers themselves get a much greater understanding of customer needs which will be useful in future projects.

A popular way to document requirements is through user stories. User stories are short, so there will be much less documentation than usual. When there is little documentation, it is harder to determine by testing what is right or wrong behavior. The documentation must be replaced by more communication within the team and with the customer. This will become possible because the whole team is not segregated and is working together, bringing about more opportunity to learn and use your own specialized knowledge for the greater good of the team and the work you’re doing.