I am the team leader in a small project. My team has 3 full-stack devs and one QA. We have an external client (PO) and internal PM. We are trying to implement the Scrum methodology but we have a lot of problems with fit in the sprint time.

For example, we have two last days of the sprint and the QA is receiving an issue to test but he is not available because he is occupied on the other project. And we don't want to wait for the feedback and also this feedback from QA will be available after the sprint ends. So we decide to move out of the sprint our QA but this is not possible to receive how to measure issue.

I know that the better solution for that will be Kanban but our PM doesn't think in this way.

Did you meet a problem like this?

  • 3
    Citing Master Yoda: "Do, or do not. There is no Try" - either you do Scrum, or you do something else. If your QA person isn't available when needed, she's not part of the team, and you have an impediment to clear. Commented Jul 14, 2020 at 11:07
  • 1
    Citing Master Procrustes. There is only scrum or not scrum. If you have trouble implementing scrum, the problem is not with scrum. Scrum does not adapt. Scrum is not scrumbut. All difficulties are in you, not in scrum. If your process does not match scrum, you must change yourself because scrum is the true path. (To be clear, I'm mocking scrum zealotry; no offense is intended to any individual. Please don't take this seriously enough to be offended).
    – MCW
    Commented Jul 14, 2020 at 11:54
  • The assumption that Kanban could address this problem is dangerous. The underlying problem may not be the tool, but the way the available people is used. There's no methodology (waterfall, agile, xGh) I'm aware of that could solve the problem or a resource (that may or may not be a person) not being available.
    – Tiago Cardoso
    Commented Jul 15, 2020 at 20:36

4 Answers 4


There are a few things that I can see that are hampering you.

Scrum is a framework designed around a product being built and supported by a cross-functional, self-organizing team. Since you talk about projects and people working on multiple projects, Scrum may not be the best fit for you. Even if it "works", you won't get the full advantages if people are attending multiple different events from different Scrum Teams that they are supporting.

One option is to try Scrum as it was intended. Form a team around a single product or "project" and ensure that they are highly focused on that effort. Make sure the team has what they need in terms of knowledge, skills, and resources to do the work that's in front of them.

Another option is to abandon Scrum. There's insufficient details for me to give any reasonable advice on things to try, but most of the formalized Agile methods are around building projects around individuals, not moving individuals around projects - this is one of the underlying principles of the Manifesto for Agile Software Development. You may need to go back to project and product management foundations and roll your own, but even so, you may find that your organization is not of the appropriate size or structure to do what you want to do.


There are basically only two ways to deal with this type of situation: fix it or accept it.

Part time people on teams and/or projects cause major issues. You loose productivity because of constant context switching. You loose time because you wait for people to become available while they work for someone else's team/project. Your planning gets messed up because you plan on what you can see and have some control over (which is your own backyard, not someone else's backyard). Releases get delayed. Bottlenecks occur. Etc.

You can use Scrum, switch to Kanban, or use something else, but it won't make any difference. Your problem is not with the process you are using, but with the resources needed to keep that process running properly. So you can either fix it or accept it.

Fix it

Every team gets their own QA. Either you hire more people, or the developers pick up the QA tasks. This way you have no external dependencies, no waiting for people to become available, and no context switching. Each team gets what they need to be cross-functional and self-organize, which is what Scrum says you should do.

Accept it

If the company can't afford more people or you keep developers only on development tasks, and you have to share a QA, then everyone must understand that the whole setup is suboptimal and all those issues I mentioned above will occur. You accept that and try to figure out ways to minimize the problems. One way to do that is to plan together with all teams and then everyone agrees on when they can have access to the shared person, then respect that agreement. Of course this adds more coordination which in turns takes even more time, and you can always have emergencies or exceptions throwing you back in the same ugly situation you began with, but you need to accept that too if you don't want to fix it properly.


One way to mitigate this problem is to focus on creating automated regression tests.

This will:

  • Reduce your dependency on manual testing and hence on the QA
  • Mean that each team member is capable of working on development or testing

In the short-term this may have an impact on the output from the team. But in the medium and long-term the automated regression test coverage will enable the team to move at speed and with confidence.


This is a classic challenge with teams starting in Scrum. Most teams are not used to working in this way and moving to these small product increments will have a few bumps in the road. A few things to consider that may help:

Timing and Availability:

You want a consistent sprint length and timing of events. If you have a 2-week sprint that starts on Tuesday, you should stay with that. This will allow people to adjust their schedules to match that. In the case of your QA person, you may want to make sure you are starting your sprint at a time that works best for them or they may been to block off the last few days as unavailable for other work. (I'll get to the multiple teams thing next)

Dedicated Team:

Generally speaking, dedicated teams are preferred when doing team work. What happens when we split people up onto multiple teams and efforts is that we lose time to context switching and schedule problems. Often, we lose more time to that than we gain by "efficient" scheduling of people. Studies have found that we lose as much as 20% capacity to context switching for each extra effort we split our time onto. That said, if you can't reach that goal just yet, the next best thing is to at least have consistent availability to plan around. This can reduce the negative impact of that multitasking.

Stop Starting, Start Finishing:

It is common that team members divide and conquer on a number of backlog items which are worked on over the course of the sprint, often passed to QA at the end, the hopefully wrapped up by the last day. This is often a stressful and frustrating experience for everyone. Rather, teams often find more success in rallying around a few (or even one) backlog item and moving them along quickly. In these cases, the average backlog item moves from start to finished in 2 - 3 days, meaning all members of your team are engaged throughout the sprint. Also, it means of one or two items don't wrap up, you aren't left with nothing.

Finally, a thought on Kanban

Every team I've worked with who used Kanban because they couldn't manage the constraints of Scrum actually had more trouble. While Kanban doesn't enforce a lot of rules, one of the things it asks us to do is measure and observe flow of work and it will spotlight those challenges that you are already seeing. If you aren't making changes to your process to address those flow challenges, you aren't getting anything out of Kanban.

  • "when we split people up onto multiple teams and efforts is that we lose time to context switching and schedule problems" - a counter argument: if there's a separate functional team that's shared across multiple projects you can overcommit (similar to cloud infra) - when ProjectA doesn't need resources they can be utilized by ProjectB. Both projects will work faster. And if the projects are closely related there might not be a lot of context switching. I think both approaches have cons/pros depending (as usually) on the situation. Commented Jul 14, 2020 at 15:32
  • There is definitely a lot of nuance in this topic. A lot of factors play into the context switching penalty including similarity of context and tasks. The way the question was written, it didn't sound like they've got an environment where matrixing is a smooth-running setup. There is almost no case where asking an individual to just around different teams and projects results in a more efficient system.
    – Daniel
    Commented Jul 14, 2020 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.