Understanding what the business users are trying to achieve can significantly help you focus the project on things that really matter. In this excerpt from Gojko Adzic's book Specification by Example, the author offers some tips for effectively collaborating on the project scope when you don’t have high-level control of the project.

Should you diligently produce multiple big documents before testing begins? Consultant Fiona Charles argues that you should do that only if you believe that documentation is your product as a tester. If your product is information, you should instead minimize test documentation and engage with the software to build the product your stakeholders are paying for.

When Mary Gorman and Ellen Gottesdiener facilitated a game called The Backlog Is in the Eye of the Beholder for the Boston chapter of the International Institute of Business Analysis, both the players and the facilitators learned some important lessons in organizing a project requirements backlog. In this article, they describe the game and what it revealed, including the value of truly knowing your stakeholders.

The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.