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.

Are you sure you want to stop them from reaching ahead? If you prevent developers from looking at (iteration+1), then in the next iteration they will take that much longer to accomplish their dev tasks. Which means your QA will have that much less time to test things.

On our team, a recurring theme is actually the opposite, developers tend to over-commit so they either don’t get their tasks done or get them done right towards the end. This has the effect of QA not having enough work in first 2/3 of iteration and way too much work at the end.

One of the ideas we’ve thrown around is to actually try to do what your team is already doing. Make developers take on less work and finish early so they can start looking at (iteration+1). This way some stories will get done earlier so that a) QA will not be bored in the beginning and overwhelmed at the end. Also in planning we would have better task estimates since people already had a chance to review the work ahead.

Being a developer and being a tester takes very different personalities and very different skill sets. I can see how most of your developers would be hesitant about jumping regularly into QA. Not only would they simply not enjoy their jobs as much, but you will also not get the same quality out of a developer “forced” to test, rather than hiring one more QA person who actually enjoys what they do.

Just my opinion (and I am a developer)

Why is the testing effort and business acceptance taking so long?

It sounds to me like you’re planning mini-waterfall projects within your iterations (developing, then testing, then acceptance). Testing and accepting should be done directly after each user story is finished, and preferably by the people who developed it plus a product owner. It should not take longer than one, maybe two hours (if you streamline this it could be done in minutes).

There are some solutions for now. You can have the development team research new technologies one day in the week to keep them busy. In this day it might be a good idea for them to look into their testing processes, since they seem to have a problem with testing (they don’t like it). Perhaps they can spend their extra time developing an automated test environment that goes beyond some simple unit tests (unit testing is just one of a multitude of testing techniques).

As long as you keep pushing for more stories during the sprint it will be hard to avoid this behavior.
Instead let people spend the rest of the sprint with whatever they are up to, except new stories. I guess there is a myriad of things that can be done: from build automation, learning that cool new tool from last week, testing or having that barbecue that you could have had for weeks.
A new sprint can be planned accordingly in order to do more stories in a new iteration (if that is the goal).

If you can speed up test and acceptance, then do so. If you can’t, this is a limiting factor.

What is happening during testing, and why does it takes so long?

It could be a resource issue (5 developers, one tester – not going to work)

Or maybe testing is overly thorough AND not finding any issue any way – in which case just test less and automate more?

Or maybe quality is poor and it takes a lot of time to test because there is a lot of rework/fixing required? In which case developers need to slow down and build better quality in (and eventually consider having QA work with them during development).

Someone smart (I’m too lazy to look it up) said that the job of a developer is to put QA out of business.

I have seen developers who finish early because they are not thorough. In my book, developers have no less responsibility for testing than testers, so if testers are finding many things that need to be reported, it adds both administrative time and later on re-testing time.

Developers can build very impressive collections of unit tests to run and still the code can have spectacular failures. Perhaps the cause is that they are considering the required functionality too narrowly. Perhaps it may go back to the use cases which may need to call out more alternate flows. Or perhaps it is a sign of poor code quality matched up with too few or too naive unit tests.

In some development environments, there may be many features that are tested with simulators or given a pass because they are too hard for developers to test with what they have available at their desk. In the interest of fairness, the scope of developer test vs. acceptance test is a huge factor in how much testers must work.

Another consideration is the ratio of developers to testers and the complexity of the test configuration relative to the tools available to automate the testing. If development runs unit tests in ten minutes, but complex user interactions or tests with hardware and external devices are not part of their testing, perhaps it is normal for the testers to be long pole. Testers may do a lot more to document their work than developers and if this is true there might be some kind of assessment about whether one side is taking short cuts or the other is doing unnecessary work.

Developers should not influence testers in ways that compromise their objectivity. However, I think is it very reasonable for developers to share documentation about their unit testing and the code that was changed with testers. In some groups, developers do a bunch of work, then hand off builds to testers when the schedule is almost exhausted. In other groups, testers get daily builds, so testing can proceed with new bits as they become available. In some groups, testers can even generate their own builds that are timed to their best advantage.

Some teams are adding people with the title Software Development Engineer in Test so that they can have highly trained staff to do code/decision coverage testing. This may run counter to some Agile guidelines, but so do the developer test practices that we say we should do but don’t.