How do you keep QA involved early in Agile without slowing sprint velocity?

That usually reduces surprises later. But I have also seen pushback that too much upfront test discussion slows planning and overcomplicates stories that are meant to stay lightweight.

If timely refinement reduces surprises and helps ensure work is ready for Sprint Planning, why is it too much?

What, exactly, is "QA" in your organization?

Too often, "QA" is used to mean "testing", and it seems like this is how you're using it.

I'm a bit confused by the pushback you're getting. The more work you do up-front, the slower planning and the "getting ready" steps are. However, there's always a balance. Reducing surprises means that the team has a much better idea of what they are actually capable of and can make better forecasts and commitments regarding the work they can complete and the goals they are likely to be able to achieve.

There's no one right balance to how much up-front work to do. Every organization, even ever product or maybe every team is different. But the approaches that you're using are very consistent with what I'd consider good practices. Which once you choose to use are context sensitive.

I agree with the earlier posts that “too much upfront discussion” is probably not the real issue. Early QA involvement usually saves time later. It does not slow things down overall, unless discussions are more detailed than required.

If QA still gets pushed to the end of the Sprint, there are usually two main reasons:

• Stories are too large, and the team is working in silos.

If a story is almost the size of a Sprint, testing will naturally pile up at the end. Break stories down so they take no more than 2–3 days. When stories are smaller, QA can start testing early in the Sprint while development continues on the next item.

This may still sound like “dev then QA,” but the key is cross-functionality. The whole team owns quality. Developers can help with automated tests. QA can be involved in acceptance criteria and embedding test thinking from the start.

Smaller stories and teamwork reduce late-Sprint pressure significantly.
 

The point is to reduce the risk of failing late in the Sprint, thus even if the Backlog Items are large the testing strategy should involve testing parts of the implementation early (even from Dev branches, even with some hacks mocks etc ).
Also, despite the Backlog Item is not completed yet, merging parts of the implementation and regression testing with the rest of the system should be happening constantly. Thus the test automation is crucial. Although the testing is the compromise between the speed/risk/cost - different strategy for different level of quality required, depending on what is being built.
Per Scrum "Quality does not decrease" during the Sprint. 
 

Just to emphasize, I think you are doing the right things.

• Writing test notes directly inside stories during grooming instead of separate test plans
• Calling out risk areas rather than enumerating full test cases upfront
• Pairing QA with devs during implementation for complex work
• Defining exit criteria that are realistic within sprint boundaries

I have done this once before and it worked really well, but takes a lot of buyins

I had a quality engineer write the test cases once a story is pulled into a sprint.  Then there will be a review between the PO/PM, QE and SE to agree on the testcases. 

This was super helpful to developers to understand what the QE would be looking for when testing, and we actually took it to the next level to say that the developer owned these test cases passing.

This helped elevate the QE team to work on the system level, and beyond verifying stories.