mitigating incomplete SPBIs

hey guys. i've been practicing scrum for about 3 months and i have a question.

problem: most of our sprint backlog items rarely become done until the last day of the sprint. development of each back log item generally is coded on separately. therefore many stories are in progress at once. if the first two were done, then 3-7 might be in progress. question: should we find a way to work on only one story at once, by many developers, so that it becomes done sooner and only 1 story in progress is in jeopardy of not being completed, as opposed to 5 open half complete stories. we've had the latter happen a few times, despite the burndown being on track leading up to the last few days. our team feels that sharing a story between developers would fall under "brooks' law" from the "mythical man month". and generally i must agree. but i'm hoping there's some middle ground, in that we can transition stories to done sooner and limit the amount of concurrent stories in progress. background: we work pretty hard during refinement to split stories into micro-stories, each with one single piece of verification criteria. and we work pretty hard to ensure the highest standards of code quality and test-ability that we can. so i don't know that we could blame lack of refinement or too difficult a story. we could probably say that our estimations as poor, and that we fall toward the right side of the bell curve for missing tasks during planning. each developer tends to work on a story in isolation. the stories are independent from each other. we start our daily scrum by analyzing the burndown. it's usually close to being on track. if it's on track, we just assign tasks. when it's off track, we discuss what we can do to get it on track using techniques like seeking help from an informed party or abandoning that lower priority story to help ensure something higher priority gets done. therefore, it's very common to see the highest four incomplete stories undergoing work, each story with tasks assigned to only one developer. this is opposed to maybe only the highest priority story being worked on by several developers. we do try to get dedicated testers to help black box test the story and regression test system during the sprint, but usually they're not delivered anything new for a given story for a couple of days and sometimes it can be a week to even a week and a half before they receive anything. that's generally a complain of theirs every retro. during the time they don't receive a new build, the code they would receive is constantly under design review, code review, and unit test (well most of it anyway, the legacy stuff proves challenging in that arena, even with michael feather's great book to aid). when we first got the project, it is >100KLOC. it fully compiles in 15 minutes, incremental build vary widely between 30s-8m. that's even with g++ ccache. our first order of business was to tweaked the configuration so that most of what we work on builds <10s incremental, <30s full. it's only until final reintegration/testing where we need to work with the regular configuation. sometimes to develop a story, we must perform some lengthy refactoring of legacy code, which isn't under test and builds in lengthy intervals, so that we can bring that code under test in our special configuration, or at least seam that code from our special configuration and bring our additions under test. this may be one of the reasons why the code doesn't get delivered to the testers sooner, it's often a task in itself to refactor that legacy code into a postion where we can test our changes to it without having to wait 8 minutes for every change to compile -- which if left unchanged would probably take just as long to get to testers. i guess we're paying the technical debt the original developers left, and they'll reap the reward when they go to maintain our features. so yeah... is there a way we can share a story and work on it concurrently? the best we've done, is agree on an interface, but we are struggling to TDD the interface and so as the individuals undergo work on their halves, they find through TDD that the interface needs to change, and it seems then that the other half's work and test are invalidated and forced to start back at square one. if there is no way to split the work, what can we do to get testers code sooner? how can we prevent so many stories from being in jeopardy of not being completed? this sprint, we just abandoned work on 3 of the 5 stories, and developers began to help the testers black box /acceptance test the 2 higher priority stories, and because we found a few bugs in them late, we never really got 100% confidence they were done, only 96%. anon230

p.s. why can't we format these messages into paragraphs?