How to Sprint Plan when QA always lags behind Development

Leadership hates that I do this and want me to go back to the strict "ALL stories must be coded, tested, and closed by the end of every sprint or they can't be included in Sprint Planning."

Why not help leadership with that, and leverage their sponsorship for completing Done work every Spriht, and for respecting the rules of Scrum?

An organizational constraint on QA skills has been exposed. How would management prefer to tackle this issue? Would they rather hire additional people with those skills, or take the time each Sprint to cross-train those they already have? Bear in mind that the current Sprint velocity is fake, and cannot be used for Sprint Planning, if it does not reflect the rate at which Done work is actually completed.

Leaving the particular roles aside, are the QA activities starting early? Is someone ensuring that your Product Backlog Items are written in a way that ensures they are testable? Is someone starting to think about design for testability as soon as work on the item starts? Some things can be done related to QA activities throughout the development process. If you wait until code complete to start any of them, you're going to be behind for sure. QA should be doing something at every step of the development process and not just tacked on at the end.

Are the engineers taking steps to maximize the quality of their work? You don't have to be in QA to take steps to ensure that when the work gets to the QA stage, the chances of finding a defect are low. Personally, I view a separate QA step as a safety net. If you're falling so often that you are regularly relying on that net to save you, you probably need to practice and build your skills more.

What are you doing to tear down the silo walls between Engineering and QA? If your system really is so complex that it takes a great deal of effort to start learning about other parts of the system, it's time to start getting people trained to be more cross-functional. Reducing the human burden via automation is also key.

I suppose if you have that kind of set-up with more or less two teams, one for development, one for QA, in the same Scrum Team, you will always have that issue.

In Sprint #1, QA will have nothing to do at the very beginning of the Sprint, waiting for developers to get something ready for test. And if you only take as many items as both can finish, your developers will have nothing to do at the end of the Sprint, as you are waiting only on the QA to be done.

So you have three options,

1. you have everything done at the end of the Sprint and have part of the team idle for a certain period in the sprint
2. you take over QA stuff to the next Sprint, to always have everyone working
3. you consider the set-up of the team and the processes, for example to seperate the team into a development and a QA team, while QA does not need to follow SCRUM, but some FIFO list to get things done.

Any advice would be helpful!

@Gayla Nader, If I said that your Scrum Team has to create a potentially releasable Increment that is Done at least by the end of the Sprint, then what do you think the Scrum Team can change or start doing to get there?

Also, I didn't see the mention of the Scrum Team achieving specific outcomes but I did observe the mention of "1-3 stories always carry over". What should be done to change this to achieving specific outcomes (Increment still has to be potentially releasable and Done) vs outputs every Sprint?

Would love to hear your thoughts.

In response to:

So you have three options,

1. you have everything done at the end of the Sprint and have part of the team idle for a certain period in the sprint
2. you take over QA stuff to the next Sprint, to always have everyone working
3. you consider the set-up of the team and the processes, for example to seperate the team into a development and a QA team, while QA does not need to follow SCRUM, but some FIFO list to get things done.

I prefer #2 so that we are always productive and all team members have something to do. What if QA is stuck in regression testing? Are the Devs supposed to do nothing since their work may not get QA'd by the end of the sprint? I'm not understanding why it can't be more flexible, especially when we don't deliver anything to customers at the end of a sprint; we deliver quarterly.

@https://www.scrum.org/user/240997 - I just feel that we could be so much more productive if I could plan for the whole team's work during the sprint and not just the QA team. I get that it's supposed to be all one team, but that isn't realistic at my company due to the steep learning curve. If I'm only planning for what the QA members can do, I'm planning for 16 story points. If I focus on what the Devs can do, I'm planning for 32 story points. The QA team then lags behind about a 1/2 sprint, but they catch up quickly and always have something to do. We don't have unit testing or automated testing yet; we are too young of an org.

How do I @ someone on here? I've never done this before.

I prefer #2 so that we are always productive and all team members have something to do. 

I'd suggest that these are quite different things: all team members may well have something to do, but they are not necessarily productive. Productivity is the rate at which valuable work is Done and made available for immediate release, which in your case is apparently constrained by QA. Remember that anything less than Done represents the accumulation of technical debt, such as missing testing, which then has to be remediated in future Sprints.

@Gayla Nader, Would it be possible to focus on a specific outcome, no matter how small every Sprint such that the work is both Developed and Tested? If excess capacity remains within the same Sprint, can you repeat the process? Is this something you can try?

How do I @ someone on here? I've never done this before.

I highlight the person's name, copy.  Then type @<paste what i copied here>.  Always seems to work for me. 

Now on the real question.

You keep mentioning that there is a steep learning curve and it is just not practical to have anyone but QA do the testing.  But it seems to me that you have people that have already climbed that steep learning curve and could help with testing. Their titles are developers.  I have been in QA for 20+ years, I've worked in agile environments for over half of that time.  I have been Scrum Master/Agile Coach for about 5 of those years.  It is very possible to code, test and deliver within a 2 week timebox.  But it requires that everyone on the team participate in all of those activities.  Yes, you can have Developers and QA titles.  However any good developer will be able to do some level of validation of their or others changes in the codebase for which they are familiar.  QA can do more than test.  They can help with discovery of requirements, they can provide input to the developers that will actually prevent defects, they can do code reviews. In a well functioning team, everyone will do anything that they are capable of doing in order to deliver. 

@Ian Mitchell has mentioned that you have discovered an organizational issue related to QA.  You mentioned that your leadership wants you to quit the practice of carrying over QA activity to future Sprints. It seems to me that your leadership might be willing to help address the organizational issue but you aren't willing to.  Is yours the only Scrum Team in the company?  If not, how are other teams dealing with it?  What does your team think is the right way to solve the problem given leadership's expectations?  

As Scrum Master it isn't your job to tell the team how to operate.  You are there to facilitate their success.  So the team needs to decide how it will work best and you can help facilitate.  If the team feels that carrying over QA activities is the right way to operate, then you will have to work with your leadership team to address the problem.  But remember, that you are presenting a false sense of accomplishment as you are not delivering completed increments in each Sprint and your the velocity you claim is invalid.  You need to be transparent with your actual accomplishments so that no one has any false impressions. 

I'm going close by saying it is my opinion that you are doing the wrong thing by encouraging work to be carried over. You are in effect encouraging 2 separate overlapping sprints where one team codes and another team tests.  This goes against the Scrum framework's practice of delivering increments that meet the Definition of Done at the end of every Sprint. No one said it is easy and in order for any agile practices to be beneficial the entire organization has to be willing to make changes to "the way we have always done it".  

@Daniel Wilhite - Fair enough, makes sense. What if the Devs complete all of their Stories and they've worked on technical debt and there is nothing for them to really help with? What do you think of them going into the Backlog and pulling in the highest priority ticket and conducting discovery, research, and design to get it started? So the team is still meeting their sprint goal and these extra items are just a bonus. We don't have large teams - 4 Devs and 2 QA on each team. Devs can't QA their own work (I'm not talking about making sure they test out their code before they make a commit - they should do that automatically). I'm talking about actual QA that moves the Story to a Done state. I just don't want SEs to be idle when their work is so valuable and they can get so much more done if they just continue working.

@Gia Madson

I just don't want SEs to be idle when their work is so valuable and they can get so much more done if they just continue working.

But can they really get things done?

I'm talking about actual QA that moves the Story to a Done state.

It sounds like QA is also needed for things to actually get done.

If the Developers conduct the discovery, research, design without the QA being involved, do you think that will actually help the situation?  In my experience that would put the QA even further behind.  And QA being involved in those activities can help to prevent defects or design issues as they typically represent the user perspectives.  But if the team thinks that is a good idea, I suggest attempting it as an experiment.  Make it clear it is an EXPERIMENT.  Do it for 3-4 Sprints and see what kind of impact it has on the team and your problem.  Inspect the activity and impact, adapt it as necessary.  (See what I did there?).  

You are not going to find a simple, quick fix.  If your team feels it is a problem then challenge them to come up with solutions.  Experiment and tweek them until you find something is actually having a positive impact.  

In your Sprint, pull only as many tickets or User Stories that can be Released by End of Sprint.

QA need not sit idle. They can work on writing test cases or creating test automation scripts if they do.

During the end days of the Sprint, Developers can work on analyzing tickets/User Stories in the backlog as a prep work for next Sprint.

This way you should be able to avoid carry over of items from Sprint to Sprint.