In an Agile environment think of a test plan less in terms of a formal document and more as
that sometimes will result in documentation, sometimes detailed, sometimes none. The key thing is to go over logic, conditions, exceptions and the like with the developer(s) before they start coding to both determine how to test the change and also to think of what other consequences should be considered. This is the best point in an Agile environment to add value as a QA person.
The earlier you can add such input the easier and the less it will cost the company in rework and bad data. It's more effective to build in quality than to have to criticize and retro-fit afterwards.
This can require Quality Engineers to be more engaged and proactive than in traditional waterfall environments.
If the feature or change is anything more than trivial and you or another will be testing the change in the future under various conditions expecting certain results to see how it works you will want to document any key points uncovered in the conversation for testing in a test plan.
Test plans developed in this way fit in well with the core Agile principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan