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?
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:
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.
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.
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.
Try to identify the cause of the problem first. I can suggest some possible causes:
Sprints are too long. Five to ten working days is a good length for a sprint. The problem with sprints of longer duration is that estimation tends to be harder, the team is more likely to overcommit, do too much context switching and then hit unforeseen problems.
Unexpected work. Again this can be caused by having sprints that are too long, meaning unexpected items arise that need addressing before the sprint is done. Problems with resource management and prioritisation can also be a factor.
Flawed estimation. The team has to forecast during sprint planning what they can realistically achieve during a sprint. Avoid absolute estimation (days and hours). If the team feel the need to size up backlog items in numerical terms then use relative estimation (points). Previous sprint velocity is a good guide to what can be completed but it is only a guide and the team's judgement is more important than the number they put on velocity. If you frequently have uncompleted work in a sprint then that suggests the team aren't inspecting and adapting based on their past performance.
Lack of test automation. Creating tests can and should be done in parallel with code development. If you have your tests created and a suitable automation framework in place then automated execution should take very little time.
Weak DoD discipline. The definition of done means that a story is either 100% done (testing included of course) or 0% done. The team should self-organise to make sure they are all taking DoD seriously.
My suggestion would be:
