I'd start by looking at the answers to this question.

If automated testing is simply not possible (it happens - I live there despite my attempts to get some kind of automated regression going. Being the only tester makes the effort to automate somewhere between challenging and impossible), I'd suggest something like this:

• Identify highest priority test cases - each sprint, prioritize all your test cases, and flag those with the highest priority. I'd use a combination of risk and steel thread to decide. These get added to your regression test suite and prioritized in context with the other tests there.
• Start the sprint with regression - as testers, we'll typically have little in the way of new work to test at the start of a sprint. In addition to using this time to plan the testing for the current sprint, use it to run regression test cases for previous sprints. If you're starting sprint 10, you would run regression test cases for sprints 1 - 8 (because there's no changes to sprint 9 code yet). In sprint 11 you run test cases for sprints 1 - 9. And so on.
• Prioritize aggressively - you're working to a timebox, so you can't do everything. If the work for the current sprint means you can only cover the ten highest priority regression test cases, then that's what you cover
• Document your regression - make sure that your part of each sprint review includes what you did not regression-test and why.
• Be sane - No matter what the application is, there will be parts of it that will receive near-continuous attention and use. If you pay attention to these areas while you are using them on your way to your actual test cases, you will effectively give them basic regression. It may not be ideal, but it can be enough.
• Treat your test suites as a backlog - and groom them aggressively. If a test case isn't relevant anymore, don't hesitate to retire it. If one needs updating, update it.
• Give your test cases execution time estimates - if you know about how long it takes to run each test case, you can use this in your test estimation and planning. Sadly, not all tooling supports this, so you may have to add the estimates to the title or body of your test case.
• Plan test cases as part of the sprint planning - Your regression test cases are as much a part of the sprint planning as any other activity. Build them into the sprint planning session if at all possible. If not, figure out beforehand how much time you're going to commit to regression testing, and lower your availability for the sprint accordingly.

I'd start by looking at the answers to this question.

If automated testing is simply not possible (it happens - I live there despite my attempts to get some kind of automated regression going. Being the only tester makes the effort to automate somewhere between challenging and impossible), I'd suggest something like this:

• Identify highest priority test cases - each sprint, prioritize all your test cases, and flag those with the highest priority. I'd use a combination of risk and steel thread to decide. These get added to your regression test suite and prioritized in context with the other tests there.
• Start the sprint with regression - as testers, we'll typically have little in the way of new work to test at the start of a sprint. In addition to using this time to plan the testing for the current sprint, use it to run regression test cases for previous sprints. If you're starting sprint 10, you would run regression test cases for sprints 1 - 8 (because there's no changes to sprint 9 code yet). In sprint 11 you run test cases for sprints 1 - 9. And so on.
• Prioritize aggressively - you're working to a timebox, so you can't do everything. If the work for the current sprint means you can only cover the ten highest priority regression test cases, then that's what you cover
• Document your regression - make sure that your part of each sprint review includes what you did not regression-test and why.
• Be sane - No matter what the application is, there will be parts of it that will receive near-continuous attention and use. If you pay attention to these areas while you are using them on your way to your actual test cases, you will effectively give them basic regression. It may not be ideal, but it can be enough.
• Treat your test suites as a backlog - and groom them aggressively. If a test case isn't relevant anymore, don't hesitate to retire it. If one needs updating, update it.
• Give your test cases execution time estimates - if you know about how long it takes to run each test case, you can use this in your test estimation and planning. Sadly, not all tooling supports this, so you may have to add the estimates to the title or body of your test case.
• Plan test cases as part of the sprint planning - Your regression test cases are as much a part of the sprint planning as any other activity. Build them into the sprint planning session if at all possible. If not, figure out beforehand how much time you're going to commit to regression testing, and lower your availability for the sprint accordingly.