I've convinced our organization to move to a full-team definition of Done, i.e. one that includes the QA testing and not just code completion. As a result, we can now more accurately tell where the bottlenecks are and see what our real velocity is. As well, this project continuously integrates and deploys regularly. Prior to this, code-complete items were considered done, and QA would routinely be getting around to accepting stories from 3-5 sprints ago. They would only get the delivered code at the end of the sprint.So, as you can expect, things are running much more smoothly, but I have a question that hasn't quite been answered before in my search. Even with sprinting, there seems to be a max time in the sprint that a story can be finished by developers and deployed before there isn't sufficient time left for QA. Depending on the story and volume of things that still need testing, this seems to be about 2-3 days before sprint end.Currently, we just continue working on things and just move all items not accepted by QA (i.e. things in progress and things deployed but not tested) to the next sprint if they are unable to complete testing. Is this an OK practice? Some devs that were used to working under the old system complain that this doesn't give the developers credit for completing the work that they were assigned, but I feel that the idea is to get a picture of what the whole team did, not just development. The end-user gets no value from things not tested and deployed. However, this process is having a tendency to pre-load the next sprint, which makes planning slightly more problematic.Additionally, I have heard that having an end of sprint developer lull is actually OK. Should we be instead looking to leave some open developer time at the end?
Handling the end of sprint cycle between testers and developers
agile;scrum;sprint