We have an issue in our Scrum Agile process, where all the developers get PBI (Product Backlog Item) 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 fix this end-of-sprint rush?

Should we break the PBI into smaller stories?

  • 3
    What are the reasons for your team to use sprints, rather than focus on continuous delivery, aimed at optimizing cycle time? Commented Oct 11, 2020 at 7:59
  • 15
    PBI? What is that?
    – dzieciou
    Commented Oct 11, 2020 at 14:28
  • 3
    Then the QA work should not be done in the same sprint, and the planning should take this into account. Where I work, QA team are sometimes testing Dev team work from two or three sprints before the current one. What are your QA people doing for the rest of the sprint, before the developers are finished?
    – Aaron F
    Commented Oct 11, 2020 at 16:16
  • 2
    @AaronF - How does this actually work? Can a story be accepted by the product owner when it has been "developed" but won't be tested for 2-3 sprints? What's the acceptance criteria? When some story fails QA 2 or 3 sprints later - and can't go into production - how is that addressed by the dev team? And then too, stories in subsequent sprints typically build on stories completed in earlier sprints - how does that work if the stuff from earlier sprints can't be relied on or is subject to change due to not working correctly?
    – davidbak
    Commented Oct 11, 2020 at 22:02
  • 3
    @dzieciou Product Backlog Item; basically an item on the 'todo list'.
    – Mr47
    Commented Oct 12, 2020 at 11:41

11 Answers 11


Get the whole team to work on the problem.

Given the arrangement you've discussed clearly the team needs to look at options to resolve this. The problem itself seems fairly endemic in all of the organizations I have worked with. It seems inevitable given the setup unless proactive steps are taken to address it.

A frequent issue is that there is no 'one team'. There is the 'developer' team and the 'QA' team. With different managers. This leads to conflicting priorities and generates the issues you are describing.
Frequently this happens when 'QA' is a mandated department as part of regulatory compliance. It's not really part of development and is seen as a separate process.

For organization where individuals are held accountable (instead of teams) this creates a significant problem. When accountability is at the individual level rather than at the team level there will be finger pointing and blaming. It's not that people are bad or negative, it's just the inevitable outcome of the reward system that they work in. To be clear 'team accountability' is actually very hard to do and means changes to traditional practices such as once a year individual reviews being the basis for compensation increases.

In order to change the culture, which is very hard I suggest looking at:

  • Backlog refinement - make sure that the question "how will we test this effectively at unit, integrated and UI levels?" is asked for every ticket. This is a big change that needs to be formally introduced and supported by the dev manager. It's simple but surprisingly powerful and effective.
  • Smaller stories - yes this is a good approach
  • Communication and respect. Make sure that the QA and dev managers work closely together and respect each other. Make sure each manager will defend the other managers work.
  • Physical and Virtual equality. Make sure the whole team is co-located together. If working remotely, ensure that QA is not treated as a second class citizen by making sure their voice is seen as equal in the development process.
  • Daily standup involvement. Make sure that QA can seek to pair with developers during daily work so they are involved with what's going on and aren't just 'verification blockers' (traditional QA).
  • Reduce the cycle time. This is hard mostly because it is counter-intuitive. "We need more time, not less!" is a natural reaction. However the industry has learned - the more frequently you release, the easier and better the testing will be. Because it has to be. There is no choice. Luckily, frequent practice (at testing and releasing) makes it perfect better. When you have to release daily you have to have effective testing to stay in business.
  • Proactively monitor remaining test time - ensure the test team report their status as "red" as soon as they see insufficient time remaining for their work. It starts getting very noticeable quickly if the test team is constantly red in the last half of a sprint because there's too much work for them to complete effectively. Have agreed on procedures for everyone helping out in those cases. Otherwise, devs may go off and make even more debt! (untested code).

This is a management issue that requires dev and QA managers to discuss and agree on the approach to champion. Each manager will need to champion and promote changes in working practices to their team. They, in turn, will need to promote and champion this approach to their management who likely agree with all the agile stuff... but have not been given feedback on the true organization changes and culture that are needed to truly support it.

  • 3
    I'd upvote this multiple times if I could. About the only addition I'd make is for the test team to start reporting their status as "red" as soon as they see insufficient time remaining for their work. It starts getting very noticeable quickly if the test team is constantly red in the last half of a sprint because there's too much work for them to complete effectively.
    – Kate Paulk
    Commented Oct 12, 2020 at 12:18
  • 1
    Added ! :) Your suggestion is my command dear colleague. Your contributions are always awesome. things like this u could also just edit it as we both give back to the community this way i trust you. Commented Oct 12, 2020 at 15:45

Great Communication Brings Great Results

Being last in line, QAs keep facing this repetitively. QA should proactively communicate delays and respective risks to stakeholders.

I’ve never seen any agile project where every sprint came in on time. Start with finding the reason what is causing the delay.

There can be multiple reasons for the delay:

  • Estimates are not very much accurate
  • Requirements are not well researched
  • Environment instability
  • Improper workload with individual resources
  • Lack of resources
  • Conflicting priorities/dependencies

Probable ways to handle such situations:

  • Keep a buffer with an actual estimate
  • Re-plan your sprint
  • Communicate delay as early as possible to stakeholders
  • Slice down stories in smaller chunks (For better accuracy in estimates)
  • Start testing as early as possible
  • Prioritize stories and accordingly move to backlog if possible
  • Limit the testing scope

Try to find one/more common causes of delay. Once you identify the cause, get together your team and start working on it to resolve it immediately.

  • Perhaps last in line is the actual problem to solve :) Commented Aug 11, 2021 at 12:06

In the spirit of working in a multi-disciplinary team, I think developers should participate in the QA process if there's a backlog of work, (or even if there isn't). I think it's bad practise for the development and QA teams not to be closely integrated - As far as possible, they should be the same team, and that makes it easier for developers to switch context to doing manual testing whenever the need arises.


Tell your devs and management that a Backlog Item isn't "done" until it is tested. So PBI don't get "done" at the end of the sprint, they remain unfinished because the team "forgot" to schedule the necessary QA.

The whole Scrum team should have a Definition of Done and QA belongs into it.

If you can handle irony or sarcasm, ask the devs why they delivered to little this sprint ...

  • I might go light on the sarcasm. Commented Oct 12, 2020 at 12:59

Not Actually Agile

As is common, people have taken a waterfall process and slapped an Agile label on it while being un-agile. The classical Agile model doesn't have a separate QA team at all. There is a single, small team, who report to a product owner. The product owner is responsible for acceptance, and the developers are responsible for pre-deployment testing. Usually through automation.


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 the original of a question cross-posted to the Project Management Stack Exchange, this answer has been cross-posted there as it is equally applicable.

  • they always say a PBI cannot be done until testing is complete, so our PM says same team Commented Oct 11, 2020 at 18:24

We have an issue

Issue for who? Sprints are a completely artificial unit of time usually set up by managers who do not do your work anyway. If you're breaking this artificial deadline but the clients and customers are happy with the product, perhaps it's time to change the way you as a team work.

One problem with the way you seem to work now is that the process eventually creates bottlenecks, which is mostly you as a Tester. That's not optimal, because the whole team becomes slow when developers eventually throw their work over the fence to your garden for testing.

A better way of going about it could be minimizing work in progress and focusing on delivering small amounts fast. That way you as a team have just a few pieces/small features in progress. You get ideally one at a time, you test it and once done, it goes to production. Much more fluid process with fewer bottlenecks. These are the ideas usually described by Kanban method, you can check it out and perhaps think about it with your team. It might work better in your context.

Should we break the PBI into smaller stories?

Well, yes. Small stories are usually more manageable no matter how you work. If your stories are huge and take days to develop, yes, they should be smaller. In Scrum, you estimate how much time work will take, you can't really estimate huge tasks, the error will be huge, only creating more problems for you and the team later on when you're running out of time (it happens surprisingly often).

Another topic to talk about here could be how you and the team test? Do you do TDD, does someone write unit tests, API tests, or do you test everything through the user interface? How fast and focused is your feedback to developers about defects and problems? Do they need to spend hours debugging?

The likely remedy will be somewhere in the intersection of these topics, but you at least can get some ideas to think about.


The QA can push back by not accepting „new work“ in the sprint, which effectively means the testing task will be delivered in the next sprint increment.

This push-back either leads to more testing and less stress, or it forces the developers to integrate the testing planning better into the development process.

This is a result of a development Organisation which needs to be shoehorned into an agile process, but it’s not the worst structuring of work you can do.

If the QA verification happens to find a lot of re-work however, you also need to work on shifting left the whole testing process.


Like some other poster said: work together as a team. To make this possible ensure you speak the same language. We have adopted BDD in our team and it's made our product owner, developers and testers speak the same language and it's made it far easier. It also means us testers can start writing test scenarios at the start of the sprint! (even if there is no implementation yet)


Read Parkinon's Law by C. Northcote Parkinson which basically says:

work expands so as to fill the time available for its completion

In practical terms, that means people, groups or teams need to be assigned smaller tasks on shorter time lines, for the whole to come together on schedule.

Isn't that broadly what project management is for?


QA happens in the following sprint.

A sprint doesn't mean that the feature has to be ready to go out to the customer at the end of the sprint. A sprint is simply a coherent package of work.

It is generally accepted that testing takes roughly the same time as development. It's entirely normal for developers to complete a feature in one sprint (to their satisfaction quality-wise), and for QA to test that feature in the next sprint. This breaks down delivery into coherent packages of work. Fixes may take place in the same sprint as QA for smaller changes, or for more substantial faults may need another dedicated round of development and QA sprints.

There is a risk that breaking this over two sprints leads to developers throwing stuff over to QA which has not been sufficiently checked, of course, but this is a problem which is endemic in any organisation which separates development and QA, and is not unique to Agile. The benefit of Agile is that at the retrospective for the next sprint, QA can raise this immediately as a project risk and developers can be tasked with doing a better job in future.

  • The result of a sprint is a potentially releasable increment. To get things Done. Done includes QA. Doing QA in the following sprint is certainly not scrum.
    – Coder14
    Commented Oct 13, 2020 at 15:03
  • 1
    @Coder14 It certainly is Agile, and a sprint certainly is not necessarily releasable. A sprint is simply a well-defined, achievable chunk of work to complete in a well-defined chunk of time. No less, and by definition of the Agile concept, no more. You may have worked in a place where they carried out development and QA in the same cycle, and considered the result releasable, but that definitely isn't the only way to do it.
    – Graham
    Commented Oct 13, 2020 at 17:57
  • @Coder14 It's releasable without QA if the Development team is "releasing" it to the QA team.
    – nick012000
    Commented Oct 14, 2020 at 7:16
  • @nick012000 That's a good way to put it, yes. "Release" just means that chunk of work is ready for the next incremental step, which may be "release" to the QA team for testing. Or it could be "release" to the rest of the development team, if it's a framework/feature for internal use.
    – Graham
    Commented Oct 14, 2020 at 8:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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