It seems to me that there is a resource allocation problem in scenarios requiring QA functional testing in order for a given feature to be 'done' within a sprint. No one seems to address this in any QA-related scrum discussion I've found so far, and the original question here is almost the same (at least related), so I wanted to offer a partial answer and extend the question a bit.
As to the specific original question about development tasks taking the full sprint - it seems that the general advice of easing up on these tasks makes sense if functional testing by QA is part of your definition of 'done'. Given lets say a 4 week sprint, if it takes about a week to test multiple features from multiple developers, then it seems like development tasks taking about 3 weeks, followed by a lag week of testing tasks taking about 1 week is the answer. QA would of course start as soon as possible be we recognize that from the last set of delivered features, there will be about a week lag. I realize that we want to get features to QA asap so you don't have this waterfall-like scenario in a sprint, but the reality is that development usually can't get real, worthwhile delivered functionality to QA until 1 to 3 weeks into the sprint. Sure there are bits and pieces here and there, but the bulk of the work is 2-3 weeks development, then about a week's testing leftover.
So here is the resource allocation problem, and my extension to the question - in the above scenario QA has time to test the planned features of a sprint (3 weeks worth of development tasks, leaving the last week for testing the features delivered last). Also let's assume QA starts to get some testable features after 1 week of development - but what about week #1 for QA, and what about week #4 for development?
If QA functional testing is part of the definition of 'done' for a feature in a sprint, then it seems this inefficiency is unavoidable. QA will be largely idle during week #1 and development will be largely idle during week #4. Of course there are some things that fill in this time naturally, like bug fix and verification, design/plan, etc., but we are essentially scheudling our resources at 75% capacity.
The obvious answer seems to be overlapping sprints for development and QA since the reality is that QA always lags beind development to some degree. Demonstrations to product owners and others would follow the QA sprint since we want features to be tested before being shown. This seems to allow more efficient use of both develoment and QA since we don't have as much wasted time. Assuming we want to keep developers developing and tester testing, I can't see a better practical solution. Perhaps I have missed something, and I hope someone can shed some light on this for me - otherwise it seems this rigid approach to scrum is flawed. Thanks.
