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?
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:
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.
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:
Probable ways to handle such situations:
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.
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 ...
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.
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?
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.
