Developers role and pull new stories in mid sprint

You are not describing a Sprint where all the Developers commit to the delivery of an usable increment of value that satisfies the Sprint Goal.  You are referring to a gated hand off of work similar to the fashion used in waterfall project management.   

In Scrum, there is no distinction made between developers and testers.  They all fall under the umbrella of Developers.  All of the Developers are accountable for completing the work in a Sprint to deliver the usable increment of value.  If part of that group does not have active work to contribute, there are many other things that they can do to contribute to the success of the team.  Those developers could spend more time updating unit, system or integration tests.  They could spend time review the items in the Product Backlog to refine and add clarity to the work that will be needed.  They could spend the time researching technologies that could be used to make the product better.  They could pair with the testers to learn more about how to do that part of the development process.  They could work on technical debt issues.  They will have to be available to fix any issues that are found by the testers in order for the increment to be usable.  Great care should be exercised to prevent the introduction of work that could put the Sprint Goal in danger of being reached. 

Speaking of the Sprint Goal, you did not mention anything about that in your original post.  The Sprint Goal is what the Developers commit to accomplishing.  Nothing should be done that could introduce a risk that it is not achieved during the Sprint. 

It is the mid of the sprint when the stories move to QA swimlane in the Jira board. During this time, what should the developers do?

They're all Developers, including QA, because their industry is needed to have a Done Increment of usable quality. What they should do in the situation you describe is to figure out how they have ended up applying such poor focus. Why are they failing to limit their work in progress, so user stories can be completed early and often?

There's a logical workflow to be followed, but that doesn't mean waterfalling a Sprint by moving the whole bolus of work stage by stage. Doing so is not only inefficient but also a very poor risk control mechanism.

This is what is currently is followed in our organisation. The company very strictly distinguishes the role between a developer and a tester and forbids overlapping of role (Why it is in this fashion, is still not clear?).

I am new to this role and team and trying to streamline the process and sprint. Currently identifying the pitfalls in the process and trying to make it more agile upto industry standards. My aim is to make the team more versatile and increase the velocity of the team.

Note : Currently at the end of the sprint our burndown chart is straight horizontal line(because of pulling in new user stories in the mid sprint). This is a big concern for the team.

I would recommend that you start with figuring out why there is a strong separation between the "developer" and "tester" roles. There are very few organizations that truly need that strong separation, and even in those cases, there are structures that can likely yield higher quality products with fewer handoffs (and handoffs turn into delays and communication overhead).

Understanding what the current state is, why it is that way, and what the smallest incremental steps to improve the way of working would help move the organization toward more frequent delivery of higher quality products and services.

We are in a similar situation to Ankita. Our "developers" are distinct from our "testers" in part for regulatory compliance reasons.

Having distinct job titles and a separation of duty is not a bad thing.  It becomes bad when there are rules that hinder communication and cooperation of the people fulfilling the roles.  It is also not great when those rules force individuals to be inefficient.  For example when Developers have to make a formal handover to Quality Assurance before any validation can begin.  This leads to Developers moving on to other work and then having to make context switches in order to address any issues discovered by Quality Assurance.  From my experience as a Software Developer and Quality Assurance Analyst, I believe that this leads to lower quality deliverables and longer delivery cycles.  I believe that Quality Control is better than Quality Assurance.  Quality Control are things implemented to ensure that the delivery has included quality measurements as the work is being done.  Quality Assurance attempts to assure that quality exists after all of the work has been completed and requires that rework be done in order to correct anything found. 

To Ian's point, batching up work and passing it between stages of your workflow is inefficient and risky. As soon as something is ready to be tested, test it. Don't wait and build it up. 

Even with distinct job titles/roles, what stops testers and developers from working together to get work to Done? If testing can't occur during coding, test cases can at least be prepared. During testing, "what should the developers do?" They could be helping other developers finish their work, or working with testers, or addressing any defects found during testing, or process improvements, or training or any number of things. Work is not done until all aspects are addressed (designing, coding, testing, integration etc.) and the team is accountable to make this happen.

My aim is to make the team more versatile and increase the velocity of the team. 

Consider changing this aim to focus on enabling the team to deliver more value and become more effective. 

Hi Rossana,

To quell my own curiosity, are you able to expand on why developers being distinct from testers is a regulatory compliance issue? This is new to me. Thanks!

We are in a similar situation to Ankita. Our "developers" are distinct from our "testers" in part for regulatory compliance reasons.

Ryan, it's a "separation of duties" thing in an organization heavily focused on security and safety, for whom software development is not the focus. We hire these roles distinctly. We're working within our team to create crossover in the skills, but we are relatively new to scrum and agile so it's a journey for us. My point was really that Ankita's situation is not unique.

Thanks Rosanna,

I am unfortunately familiar with segregation of duties as a key control, just not between coding and testing. This is one is new to me and I appreciate you providing details. For us it was segregation of development and release where the people updating code could not be the same people to deploy it to  (hopefully) avoid malicious code injection. Both are unfortunate, low trust scenarios.  

This is usually a symptom of having large user stories that take up the large part of the sprint duration. Shortening the user stories is one way to help. 

I am not getting into the role distinction. In my experience dev and testing can overlaps as much as the technical abilities allow. Dev can do initial manual testing, write unit tests etc. QA testing can do more elaborate manual  testing, develop more automated tests and evaluate fails in automated tested. 

However testing should be incorporated through-out the development and not at the end, even for a sprint, testing should be brought forward. Making stories shorter, cycle time between dev and testing shorter. In an healthy sprint there can be repeated cycles between dev and testing on the same story.  In addition tests can be written before dev is finished. I am not advocating religious TDD, but that is an example.