You should be able to handle this with appropriate branching of the scripts, especially if nobody is changing the same files/objects. It may not work as well for your shared dev environment, but should work fine for production. Separate the work by story/feature branch (if a bunch of stories), group the work done that way. You'll have some work to do to pick out all of the stories to release to production, but if they're separate you should be able to handle that. Maybe consider something like:

Dev

-Sprint1

--Story1

--Story2

When you want to release, move/copy the folders:

Release

-Sprint1

--Story2

After release, move (again, maybe with a date)

Released

-Sprint1

--Story2

It's not pretty, but you could see what you're about to release and it could be semi-ordered. If you put your stories in dependency order, that would be ideal. If not, you'll have some more tweaking to do when building the scripts. It's not a pretty process, but we worked with it for a while. It does take some discipline, especially not to just tweak an earlier script with a change because that's easier.

For DB projects, we were able to isolate changes into their own branches, then merge those branches into a mainline/master build before releasing to production. That kept the changes that weren't going to production separate while maintaining the other changes. As long as you keep any dependencies in mind, you should be fine.