We have an issue in our Scrum Agile process, where all the Developers get PBI work done in the last few days of the sprint.

And then QA is forced to test everything at end of sprint. What is the solution to fixing this end rush?

Should we break the PBI into smaller stories?

  • PBI is "Product Backlog Item", for anyone else confused. – l0b0 Oct 25 '20 at 8:19

You should not consider development and testing as sequential activities within the sprint, or the thing you describe happens. Development and testing should happen together as a collaboration between devs and testers. It requires a change in the way you work. See more details here: What does a QA team do during the development phase of a sprint in Agile Scrum?

Until you introduce this kind of change, you should at least split the PBIs in small stories that you develop and immediately test, instead of waiting until the end of the sprint (i.e. reducing as much as possible the distance between the dev and testing activities).


Yes. A common rule of thumb for a two-week sprint is that most backlog items should take 2 - 3 days to complete including QA, deployment, etc. This is just wisdom for experienced teams though, not a hard-and-fast rule. It will also take time to get there. If the team is used to a backlog item taking a full 2 weeks to complete, they aren't going to jump to 2 days right away.

There are three practices I would consider to help your team out:

  1. Breakdown backlog items in hindsight. It is common that the team won't know how to break backlog items down when they start. A good way to learn is to have a short discussion once the item is complete and ask the question: "If I could go back in time knowing what I know now, how might I break this down smaller." You can then take those lessons forward with you to similar items in the future.

  2. Move testing and QA earlier in the development process. TDD, ATDD, and BDD are all great ways of moving a large portion of testing ahead of development and streamlining the development process. These feel too extreme, try a simple three amigos meeting. In these meetings, a coder, tester, and business/user representative have a conversation before work starts. This gets a lot of the testing and functionality ideas out on the table before a line of code is written and seriously reduces back-and-forth handoffs.

  3. Group up! Of all the teams I've worked with, the problem you're describing almost always comes with people applying a divide and conquer approach to the work. This approach is usually more time efficient on the first pass, but loses way more time on integration, knowledge sharing, and testing. Pick one or two items and group up with a focus on getting few items finished quickly instead of lots of items started.

Any of these will help, but they can also be used together too. Best of luck!


There are a few different ways to approach this problem.

From a Scrum perspective, your Development Team does not have sub-teams. You may have specialists, such as people who specialize in testing, but the whole team should be involved. Rather than putting the QA specialists in a position where they must test everything at the end of the Sprint, the whole team should be involved in testing, whenever that testing occurs. The QA specialists can help train the rest of the team on good testing practices.

Not specific to Scrum, incrementally delivering the work throughout the Sprint and continuously integrating and testing it would also help relieve some of the pressure. Instead of testing at the end of the Sprint, test as work gets finished. If you are waiting until the end of the Sprint to integrate work, try to integrate it sooner. If it looks like you can’t, it could be a sign that your work is not well sized or sliced.

Finally, in some environments, there may be good reasons to have independent QA. The first two points still apply, and the Development Team should be producing a high-quality product. However, any independent integration and test should be moved outside of the Sprint and onto a separate team. If the Development Team has done a good job, this team may have feedback, but shouldn’t regularly find issues that would prevent a Sprint's output from being releasable to the next downstream process.

Since this question is an exact duplicate of a question on the Software Quality Assurance & Testing Stack Exchange, this is an exact duplicate of my answer there as it is equally applicable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.