How to handle Idle team members in Sprint

Question

I am working as a SCRUM MASTER in a TEAM of 10 people (6 DEV, 1 Designer & 3 QA). My organization has just started working in SCRUM methodology and we are having a problem in resource management - Current Scenario - Our Sprint 1 is near to completion (last week of Sprint is going) now at this point we see that Developers have no task, as the PBIs completed from their end, All the Major BUGs resolved and verified. Now only Testing team is working in Sprint as they have to complete some of the Stability testings and running failed test cases again. So, developers are free and there are no tasks for them. How to handle this case? Possible solutions that come in mind (and I am not satisfied with any of these) are:

1. Start new Sprint, as DEV can start working of new PBIs (BUT: Then QA will have the pressure of both Current and upcoming sprint at the same time)

2. Ask DEV to read PBIs and thinking about Ideas of next implementation at least (BUT: I don't want a team to discuss Ideas separately, as Sprint planning is a soul of SCRUM where QA and DEV together sit and discuss the IDEAS)

3. Ask DEV to do some research and all in order to enrich their knowledge and strength for a better team. (BUT: My Boss does not agree to pay 6 Developer to do unwanted research for 5 Days)

Please provide some IDEAs or if you have any real experience kindly share the same.

Answer 1

Seems you have a mini water-fall. Everyone in the team should help finish the Sprint. Let the developers help with the Stability testing and re-running failed test cases.

Developers and QA do not exist in Scrum, to quote the Scrum guide:

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

Try to find a way to make the individual members more cross-functional.

As a certified Scrum Master, I would expect you know this, maybe you should read the recent Scrum book of Jeff Sutherland. I just finished it and its worth the read even if you do not use Scrum :)

Just some feedback on your ideas:

Start new Sprint for as DEV can start working of new PBIs (BUT: Then QA will have the pressure of Current and upcoming sprint together)

QA will keep falling behind and even more behind. QA will take shortcuts to get back in pace, don't do it.

Ask DEV to do some research

Research is nice, but better is to optimise the amount of automated tests or removing technical-debt by refactoring code to be better maintainable. This will make the team faster in the future.

Answer 2

It can be a good time for developers to either catch up on some tasks (paying off various types of tech debt) or get a head start on some code redesign for next sprint.

It's also not necessarily a bad thing to start on next sprints work, as it might help with having a more steady stream of work. As you might find there isn't a great deal to test at a start of a sprint.

What you need to work out, is how do you make the testing requirement less bumpy. i.e. how do you test earlier, so you don't need such a big time at the end of the sprint to test changes.

Answer 3

@Neils van Reijmersdal isn't wrong, but such a strict view of Scrum isn't always healthy as every team is different, and the needs of every project vary. Scrum is meant as a guideline for successful development.

All development groups at my company (a software company with many divisions, each with their own products) have both engineers and QA analysts as separate functions. However, this does not mean that the engineers cannot perform QA tasks, or vice versa, as needed.

We tend to face the opposite issue, where in QA we are waiting for tasks to be completed by engineers. This is an easier problem to solve since exploratory testing is always an option (and there is never a "zero defect" situation).

For your particular issue, if there are truly no testing or development tasks available in the current sprint you can:

• Bring PBIs from backlog into the current sprint, even if only the development tasks are completed and the testing tasks get completed in the next sprint. There is nothing wrong with this.
• Use the time for training. Use Pluralsight or Udemy or other online courseware options, have cross-training among the engineers, or have the engineers self-learn with books or small secondary projects related to the business.
• Use the time for the engineers to meet with business analysts for cross-job training and education (this can go both ways).
• Have the engineers generate very basic test case scenarios for modules that they expect to be testing before releasing to QA. These are often basic validation scenarios, and can help the next sprint go more smoothly.

Honestly, the first is generally what we do - move items from backlog to the current sprint with only the development tasks. If there's time, pull in a testing task for the PBI as well, if not, the testing task can be part of the next sprint. This keeps all members of our team having work available.

Answer 4

You need to move to a Kanban solution where you can establish a WIP limit. As your developer completes their tasks in the story, they can start on another set of tasks in another story with no downtime (unless there are dependencies). When your WIP limit has been reached, then the team swarms to complete the 'in progress' stories.

Quite simple solution for your concern.