I personally find it useful in covering the whole project. Running through it once per release cycle is one of the best ways to make sure everything you absolutely need checked is working properly (exploritory testing helps to find anything else and should either be a part of the test plan or at least be noted elsewhere as an important part of each sprint).
The first and most obvious thing I add to a test plan is the expected process for the application/site. If your base process doesn't work as intended, it should be the first thing that's flagged since it would be the biggest issue preventing a release.
Covering your supported hardware/browsers is what I usually add next. While this (depending on the company) might not deter a release in some circumstances, it can be a big problem if multiple ports don't work properly and can be pointing to a much scarier, underlying issue that needs to be rectified ASAP.
Somewhere around here, I would begin to mention confirming the bugs that have been labeled as fixed during this (and maybe the last, if desired) sprint.
After that, I would most likely cover any common major bugs and uncommon critical errors. This step can get unweildy as a project ages, so discretion might be needed. This is mostly merging into regression territory, though.
Finally, I think an "if there's time" section is good and keeps people busy, especially during a slower sprint (maybe a "jog", in this case?). I'd consider things like checking copy or a set of common minor/trivial bugs.
I personally view a test plan as the QA team's signature of approval for a build to go live, so that explains why I add a lot of regression elements into my plans, but obviously do what works for your team.
Hope this helps.
