One of the Scrum's ideas is to have a deliverable ready after the sprint's end. Development and testing should be completed on a story within the sprint, so that it could be released/deployed.
In this case, story is like a transaction in a relational database - it is either completed at the end of the sprint or is moved to the next one.
That's an approach we are utilizing on a project and there are some concerns about it. Some team members are reasoning that we should split big stories into a separate development and QA stories and track them separately. So that dev story could be picked up in one sprint and QA story could be scheduled to execute in the next one.
Potentially that might give more flexibility/control on each team member's load but might introduce some risks on release planning etc.
I wonder what are other pros/cons of having stories split into dev/QA? Does anyone had such transition performed in his team and what results has gotten?