A test plan is more about finding the “right” scenarios than listing “all” scenarios. The later always deceives you by creating a false confidence that you’ve covered a lot quantitatively. In my experience, organizing your thinking plays a pivotal role in helping you outline the coverage matrix, and those few cases which are easily missed.
One useful pattern is creating a test matrix. Outline all the parameters which affect the behavior of a feature. Usually these fall into buckets - a) inputs from user or another component, b) the configuration of environment/ecosystem in which your application runs. Now based on the priority of a particular combination dive deeper into the scenarios by modifying these. Or you could use a pairwise testing tool to do the scenarios generation (nice introduction here). Also consider explicitly mapping the functional requirements to the scenarios.
A test matrix clearly calls out the cases you’re not covering (because of low priority etc.). This coherent presentation of the scenarios will enable anyone with understanding of functionality of this feature to review/contribute to the scenarios (may be trick your Program Manager or Developer to help you with the test scenarios ;)).