Here's a problem. Developers have some kind of a task (develop certain feature), which takes about the length of a sprint. So, by the end of the sprint developers are happy since they just finalized their part.
BUT. The product is not QAd, so it can't be distinguished as "potentially shippable" since it most likely will contain some bugs.
So, the question is: if there's NO automation tests, only human QA engineers, what's the best way to plan our sprints? To have one sprint of a delay (QA tests the items that were developed in the previous sprint)?
What can help us out in this kind of a situation? What should developers do during the QA procedure?
A very important aspect of Scrum is getting things "done" during the Sprint, and the definition of done. If a feature is finished during the sprint, but not tested it still isn't done.
What you should not do to solve this is to increment the length of your Sprints. Short sprints would still mostly be prefered. I'd suggest two things.
The first one is really important, but not necessarily easy to achieve. Integrate QA into your teams. Having a separate QA department that validates your product after you're "done" with it is really waterfall. You may still want the QA verification before your product is shipped, but what is produced in the sprint should be finished and tested during the sprint. To do so you need qualified QA people to be part of your team - or you need to train the developers to do QA as best as they can. In my company our QA department is too small, so we were unable to get some for our team. Instead we learned about QA and added a column to our task board with the heading "Ready for verification". Whenever a feature was finished it was moved to "ready for verification", and some other developer would look at this. Even though we might not have been as skilled as the dedicated QA guys we discovered problems all the time this way, moving them back for fixing, and then to Verification again. This process gave us much more confidence in the features we classified as done during the sprint, and a dramatic drop in bugs found later on.
The other things is to start defining smaller tasks, or do a better job in breaking features down into smaller parts. You don't want to work on a feature that accoring to your esimations might take the whole sprint. If your "almost done" you really haven't finished anything during the sprint. Instead; break the features down into smaller parts and solve them one by one. While someone is working on part2 part1 is being verified by one of the other team members, making the whole process of development and QA more integrated - giving a better chance of calling your new features "done" at the end of the sprint.
Good luck!