Sequencing UX-R activities is something I’ve been trying to figure out myself, and my view on this has evolved since starting Shape Up.
To protect your time to do effective UX research, two ideas we’ve tried with varying levels of success:
Offer to write pitches for research initiatives. Then you can propose appetite and problem scope. This way, the betting table might better understand trade offs if they skip/compress research. (Make sure your pitches convey the potential downside risk of not doing proper research.)
Take UX research out of the cycle and make it part of the shaping flow to inform pitches. (So once the work is shaped and bet, it shouldn’t need further demand-side research.)
I’ve grown to prefer option 2 over 1, but in either case, try not to make research a blocker to the delivery team, so you avoid that pressure of having to squeeze it in.
FWIW, one of the great benefits of Shape Up is how we’ve eliminated the need to do hi-fi screens for dev specs. We have a style guide and lo-fi sketches/wireframes, and let the delivery team build from there. As for usability testing (for us, that means testing the product once coded), we do that in the cycle itself as a delivery team task.
I know (from painful experience) a high dev-to-designer ratio can be tough, because you have competing priorities for your time. Best of luck!