Not in our case. We’re breaking work into small stories that are self-contained improvements that can (usually) move into production independently of anything else. Typically an individual or team can complete more than one in a two week period. But either way, we won’t break them any smaller than that atomic “completeness” to fit into an arbitrary time interval. The sprint is just for automatic estimating of when we’ll get to a story, how often to demo progress to interested parties, etc.
In that case, we might only be differing on terminology. In my understanding, scrum's defining feature was the fixed time box. What you described sounds like kanban to me!
I would say we are using a mix of kanban tools and the scrum process to practice agile software development philosophy. We aren’t really using the kanban process since teams shepherd their stories to completion regardless of WIP at any step. And user research is more based on the continuously evolving end goal than what is being pulled in by openings in the kanban board. But yes, we are not trying to define two weeks of work up front, just noting what gets done every two weeks.