"How is scrum supposed to work when releasable Dev
tasks take up most of the sprint?"
As you've found out - it doesn't work terribly well :-) The process you're describing doesn't sound much like Scrum to me - or at least not like Scrum done well.
I'm unsure from what you've described whether the QA folk are part of the team - or a separate group.
If they're a separate group then this is probably a big part of the problem. They won't be involved in the team's commitment to completion of tasks - and the associated scope negotiation with the product owner. I've never seen an agile group succeed well without their being QA skills in the team. Either by having developers with a lot of testing/QA skills - or by having an embedded QA person or three on the team.
If they are on the team then they need to get their voice heard more in the initial sprint planning. By now it should be clear to the product owner and team that you're overcommitting.
I'd try a few things if it were me:
- Get QA/testing folk on the team if they're not there already
- Have a good long chat with the product owner & the team over what counts as "done". It sounds like some of the developers are still in the pre-scrum mindset of "handed over to QA"" == done.
- Break down the stories into smaller chunks - makes it easier to spot estimation mistakes
- Consider running shorter sprints - because little and more often is easier to track and learn from.
You might also find these tips about smoothing down a scrum burndown useful.
