How to complete development and testing in one sprint?

so testers aren't always playing catch up. The testers express that they are always 1-3 sprints separated

@Molly Brewer, Good question, but from this line it appears the testers are a different silo within the team? Would you truly call this group (incl. dev and testers) a team? It also looks like their concerns aren't being addressed. Why do they feel that they are behind and how would they be able to bridge the gap if they were given an opportunity to change something? Perhaps that might lead to the root causes and the solutions needed.

Also, has your team considered automating the testing process or looked at practices like TDD, BDD etc?

My question is how do I get the testers caught up and begin having development and testing done in one sprint?

If the above discussed issues result in anything, you may also want to understand if your team isn't taking in too much work i.e. trying to utilize 100% capacity.

Two questions that come to mind:

Does the team have a Definition of Done for their work? This can be used as a starting point to help get agreement and emphasize the importance of having the software tested by the end of the Sprint.

Does the team create a Sprint goal? This can be a huge motivator when it comes to the team focusing on achieving a common goal and rallying around the work to be completed. 

Coming from an organization that traditionally had development and testing very silo'd can present challenges to this mindset. Goals were often distinct to their particular area with little regards to the next area in line. 

I've seen teams where developers were very resistant to help jump in and test. I've seen others where our lead architect and developers would jump in and work with our testing specialists to help the team meet their goal if needed.

I believe the two items above can be very valuable in helping shift the mindset if you're still seeing silo'd thinking and behavior.  

My question is how do I get the testers caught up and begin having development and testing done in one sprint? It seems like the only solution is to hit pause on development work until testers are caught up, but this will not be possible as our PO's have items they need to be worked on.

How many Product Owners does your Scrum Team have? Why is there an emphasis on starting work rather than completing it? Why does the team choose to take on more work than developers and testers can jointly complete in one Sprint?

@Steve Vb

Would you truly call this group (incl. dev and testers) a team? It also looks like their concerns aren't being addressed. 

My team currently has 3 developers (normally 4, but one had to switch to a different team recently) and roughly 2 testers. Both testers are also testers for different teams. We all are co-located and everyone attends the scrum meetings, so I wouldn't consider them as a different silo. Their concerns are being addressed, which is why we are trying to figure out a solution to get the devs and testers more aligned. 

Why do they feel that they are behind and how would they be able to bridge the gap if they were given an opportunity to change something? Perhaps that might lead to the root causes and the solutions needed.

They feel behind because they are working on what the developers worked on 1-3 sprints ago. I guess I'm not sure how they would bridge the gap... If given the opportunity they would probably want developers to take a break from development so the testers can get caught up. The thing is, we know what our end goal looks like... Devs and testers will meet and discuss:

• High level tests that will be used to verify AC
• Devs then start writing code that will be necessary to make those tests pass
• Each time the development team has enough code created to make a test pass, that code is handed over to QA to execute that test against the code for the feature.

And each sprint development and testing is completed. I'm just struggling to know how we get there without completely stopping development.

Also, has your team considered automating the testing process or looked at practices like TDD, BDD etc?

Yes, that is something our testers are slowly working towards. 

 @Tony Divel

Does the team have a Definition of Done for their work? This can be used as a starting point to help get agreement and emphasize the importance of having the software tested by the end of the Sprint. Does the team create a Sprint goal? This can be a huge motivator when it comes to the team focusing on achieving a common goal and rallying around the work to be completed. 

Yes we just created a DoD a couple weeks ago in our retro. That is a very good point though.. I could probably utilize it more in planning. The problem is, we can pull in items that are small enough to be developed and tested in a sprint, but because the testers are working on items from a couple sprints ago they won't be able to work on those items pulled into the current sprint.

Yes, we also have sprint goals.

@Ian Mitchell

How many Product Owners does your Scrum Team have? Why is there an emphasis on starting work rather than completing it?

We have 2 PO's. My team works on billing and policy products, so we have a PO to represent each of those. That is a very good point.. I have never thought about it in the perspective of focusing on starting work than completing it. What would you suggest? Developers don't pull in anymore new items? 

Why does the team choose to take on more work than developers and testers can jointly complete in one Sprint?

It's not that we pull in more work than developers and testers can complete. Our stories are normally small enough to be developed and tested in a sprint, but because testers are working on testing stories from 1-3 sprints ago, they don't have time to test the new items that were pulled in until they finish the previous ones. I joined this team about 2 months ago as I had mentioned, so I think this is the norm with them, but it's a new goal of ours to help the two get caught up and starting working together.

Both testers are also testers for different teams.

@Molly Brewer, If testers are shared across different teams, how do you think that would affect their focus towards meeting the Sprint Goal? Could this be a reason why they are behind? 

Each time the development team has enough code created to make a test pass, that code is handed over to QA to execute that test against the code for the feature.

And each sprint development and testing is completed. I'm just struggling to know how we get there without completely stopping development.

If the Development Team is able to make a test pass, why is it again being handed over to QA? QA as in the testers of this team or external to this team?

I didn't quite understand how your team completed development and testing each sprint, yet you are somehow struggling and considering pausing development.

 @Steve Vb

If testers are shared across different teams, how do you think that would affect their focus towards meeting the Sprint Goal? Could this be a reason why they are behind? 

Yes that is definitely a possibility, but unfortunately, as "agile" as we say we are, we are not. And we are unable to change this.

If the Development Team is able to make a test pass, why is it again being handed over to QA? QA as in the testers of this team or external to this team?

What I meant by this is that developers break down the story into tasks. Each time a task is done and it meets the AC and can be tested, it is assigned to a tester. 

I didn't quite understand how your team completed development and testing each sprint, yet you are somehow struggling and considering pausing development.

Sorry, I may not have explained that the best. So that is something we want to work towards.. That is our goal. Currently, we pull in stories that are small enough to be developed and tested in one sprint. Because the testers are testing stories from 1-3 sprints ago, they cannot test the items that were pulled into the current sprint. So even though the stories can be developed and tested in one sprint, they are not.

In order for us to make it so they are developed and tested in one sprint, the testers have to catch up. Is the only solution to have developers quit developing until the testers are caught up? 

Please let me know if you need more clarification.. 

If the team's goal is to be able to complete the development and testing of the work within a Sprint I'd challenge them to come up with some ideas on how they could achieve this and make it sustainable so they don't end up in this situation in the future. 

Anything they development now will essentially sit and waste for at least 2-6 weeks from the sounds of it. Is there any benefit from having the team carry on as they are? 

One option might be to have the developers jump in and help quality test. Perhaps they can come up with some other ideas as well. What you don't want is to end up right back in this spot if the development side is far outpacing testing. Perhaps developing some automated test scripts could help QA keep pace? I'm not sure the context of which they're working but I'm sure the team could come up with some creative solutions. 

Yes that is definitely a possibility, but unfortunately, as "agile" as we say we are, we are not. And we are unable to change this.

@Molly Brewer, I completely understand. I've been in similar situations too. However, would it make sense to continue  "Scrumbut", if the identified impediment cannot be removed?

Because the testers are testing stories from 1-3 sprints ago, they cannot test the items that were pulled into the current sprint. So even though the stories can be developed and tested in one sprint, they are not.

Consider if your teams are really creating a "Done" Increment if you are unable to test within the Sprint, and what impact it has on value of the additive work done so far.

If work from previous Sprints are still being added to the current Sprint along with new work, are we perhaps over utilizing the Development Team and not managing WIP correctly?

Consider if you can make these issues transparent to both the management and to the teams and work towards reaching desired outcomes.

If work from previous Sprints are still being added to the current Sprint along with new work, are we perhaps over utilizing the Development Team and not managing WIP correctly?

I agree to the above point, you might be over utilizing the Dev team and failing to manage the WIP. What I can think of in this situation is, have the development team support Testing team by creating automated tests and run them . Also, they can test around the features manually, for this you can have a separate Task in your backlog and can track down to closure.

What I can also think is that Planning and estimation might not be done considering your testing team activities. Would you mind posting snapshot of your DoD so that we can suggest you better approach or solution. Cheers! 

@Venkata Naga Aditya Charan

We just created our DoD a few refinements ago:

• End to end testing completed
• Bugs triaged and tested
• Code reviewed and merged
• AC met
• Reviewed and approved by PO
• Story closed in Jira
• Unit testing completed
• Functional testing completed
• Regression testing completed 

Hi all, Does any one have the prerequisite to implement In Sprint Automation or any kind of report with which we could go forward and implement In Sprint Automation?

Thanks for thiese answers, dudes, really useful for me!