I'd like some input on this on those working with agile methodologies...A current project is finding that development on our planned user stories is finishing some time before the end of the iteration, and that the testing effort and business acceptance is what's actually dragging us out longer towards the end. This means that the devs in question have spare time, and they're essentially going out to the iteration+1 backlog and starting work on cards there before our current iteration cards are 'done'. As iteration manager, I want to put a stop to this - I want a more team-orientated approach where the group takes ownership of getting all the cards done, as opposed to Well, dev's done so what do I dev next?The problem I face is convincing the team of this. On one hand, I understand why the devs don't want to test the code they've written (there are unit tests they write of course, but the manual testing to be done could be influenced by their bias). The team sees working ahead as making our next iterations easier, because a lot of the work is done before we start. I see this as screwing with the whole system of planning/actuals - but it's difficult to convince the team as to why this matters. What advice can you guys and girls give? How do we stop devs reaching ahead? What should they be doing instead? How much of a problem is this in the scheme of things, if things are still getting done?
Finishing an iteration early
agile;estimation;planning;sprint
This is usually caused by failure, that is not delivering everything planned for the sprint, being seen as a negative thing by management. Remember the occasional failure is required to know exactly how much the team can deliver. You may also need to remind the team that their performance is partially judged on the amount of code they can deliver, not just whether they deliver the promised features in each sprint.If that is not the case, why is the team finishing work early? For example:Are they over estimating, a common problem with scrum? If so, use the finished early sprints as evidence to push the team a little harder. Are they getting assistance from outside the team? If so, add these as workers. Was time allocated to probable interruptions, such as supporting an existing product? If so, reduce the estimate for the next sprint.Also ensure that supporting tasks are done in addition to the development work, including automated tests, ensuring the product installation/deployment is up to date, documentation is complete and so on. Consider raising the completion criteria for these. Alternatively, have the dev help the QA by creating test data, automating tests cases and so on. Remember the sprint team is judged by sprint team effectiveness, not whether the devs finish their tasks early or not.