Basics first... do you have acceptance tests attached to your requirements? If not then how are you testing?

Next... On a 2 week sprint how are you defining done for an item on the sprint backlog? If testing all the way through QA isn't part of that "done" then you need to step back and rethink your process...

2 week sprints are fine... but why the rush? I realize as a startup you're trying to get stuff done and out the door... but if you're team is ending up doing a lot of bug fixing than in reality you're not saving anytime at all...

So from the top... get somebody to at least come up with acceptance tests, get an automated build server in place, get you devs to do rigorous unit testing. And... track it all.

Managment might balk, but point out that delivering buggy code and spending time to fix it is going to cost them more, it always does.

Basics first. Do you have acceptance tests attached to your requirements? If not then how are you testing?

How, on a 2 week sprint, do you define done for an item on the sprint backlog? If testing all the way through QA isn't part of that "done" then you need to step back and rethink your process.

2 week long sprints are fine but why the rush? I realize as a startup you're trying to get stuff done and out the door. However if your team is ending up doing a lot of bug fixing than in reality you're not saving any time at all.

So from the top: get somebody to at least come up with acceptance tests, get an automated build server in place, get you devs to do rigorous unit testing. And then, track it all.

Managment might balk, but point out that delivering buggy code and spending time to fix it is going to cost them more. It always does.