No. Scrum is based on time-boxed iterations, and one of the main tenets of the framework is that the Scrum Team accepts work into the Sprint based on how much work can fit within a fixed-length Sprint rather than sizing the Sprint to fit a given volume of work.
More to Think About
While it is acceptable to adjust the Sprint length to fit the Scrum Team's needs, that is a allowing for adaptation of process rather than indicating that it's okay to have variable Sprint lengths. Continuously-varying Sprint lengths is a project smell that indicates that work may be:
- Improperly-sized, rather than composed of small done/not-done chunks.
- Assigned from outside the team, driving a requirement to finish X amount of work in a given Sprint.
- Improperly prioritized on the Product Backlog.
- Insufficiently granular to make a good user story.
- Too tightly-coupled with other user stories, often indicating a missing user story or a poorly-defined epic.
There could certainly be other reasons, too, but these are a good starting point to try to figure out why you feel like standardized time-boxes are a bad fit for your group.
Scrum-Like Isn't Scrum
If you use continuously-varying Sprint lengths, you are not following Scrum. You are possibly doing something Scrum-like, and potentially something agile, but as a Scrum practitioner I wouldn't take either for granted. Scrum requires time-boxes; if you don't use time-boxing, you aren't doing Scrum.
If time-boxes with hard cut-offs are legitimately a bad fit for your work-flow, you might consider other agile frameworks that focus on different mechanics for managing iterations, cycles, and throughput. However, you should certainly make sure you understand why fixed-length iterations are a bad fit before you try to replace your methodology, or you may find yourself with a different (but still poorly-fitted) methodology for your process.