Involving QA sooner in a sprint.

How are you currently limiting Work In Progress so flow and throughput are maximized? Are the team willing and able to collaborate or swarm around WIP-limited work?

Perhaps your team is choosing to work on items that are too large to meet your Definition of Done within a sprint time box?

Vertically slicing items into smaller items has many benefits:

• Improve estimation of items (more focus, less scope)
• Improve flow of items within a sprint
• Increase level of engagement across the Development Team
• Shorten the feedback loop (gain empirical knowledge much earlier)
• Increase overall Scrum Team morale (many successes/accomplishments throughout sprint)

Review this site to gain a better understanding around how to properly split items:

https://agileforall.com/patterns-for-splitting-user-stories/

In addition to the points made, does the entire Development Team feel a sense of ownership around quality, or is testing handed off to a sub team?

If testing is handed off from a developer to a tester, how might you challenge this way of working and ask the Development Team how they might become more cross functional?  As an example, might they start pairing?

In our team, we involve the complete team in the PI meeting (the Product Management, Development, Testers, etc).  So each is aware of the context (Features which later broken down to stories). 

Parallel to developer, the Tester identify scenarios/Tests. So, if the developer has missed some bits they can also refer to the scenarios and add that bit in their development.

The tester/developer have to work closely so as the development progresses the tester accesses the developers url a gives their feedback then and there.

We create daily builds for the product. Now, the QA is already aware what if the functionality. They will just verify if the story is deployed in QA and meets expectation.

Also, the stories have to be small such that they can be delivered in the sprint.

Thank you for your feedback and suggestions.  The team has tried some of your ideas but obviously may be worth revisiting. 

"An on-going retro topic of discussion is getting stories to QA sooner in the sprint rather than towards the end."  I'm assuming QA is actually part of the development team. If so, are the development team members present during refinement sessions, planning, standup, etc? If they aren't take steps towards ensuring they are.

Once a sprint begins and items are selected - with sprint goal formualted - those writing software can hit the nail by completing tasks. Testing should be possible as early as a few tasks are completed, or, at the latest, when the coders finalized their own testing (yes, devs should test themselves, too). Regardless, QA can start as soon as work is deemed code (and initial dev test) complete. They (QAs) don't need to wait for a whole batch of tickets to be pushed to them. Have you found ways to empirically identify the software quality? Because if the quality is questionable, QAs will reject the work, in which case it will need to be fixed by the devs, which, in turn, will increase the pressure and the risks.

I'm assuming from your statement you release software once per sprint, so that means significant regression testing occurs only at the end of the sprint, which brings additional problems for the team.

Our colleagues made good points above...

"We find that stories that may roll from one sprint to the next mainly roll because they didn't get to QA in time to be completed." Rolling stories from one sprint to the next is actually very bad for many reasons. You should put efforts towards:

• limiting the amount of work pulled into sprint
• ensuring proper communication between developers and QAs on a continuous basis
• limiting the work in progress at any point in time
• ensuring your definition of done is adequately built to reflect the realities, and it is well understood by the entire development team
• ensuring there is a distributed work approach throught the sprint, from day one to last day