Scrum suggests small teams as far as I'm aware. This means that we often have single frontend developer, single backend developer, single QA engineer, etc.

Doesn't it negatively affect the project success? If, for example, a backend developer gets sick, then what should we do as a manager? Should a customer pay for our work as earlier, despite the fact that we can't produce as much value as when the whole team worked together? How should this situation be stated in a contract document?

  • 3
    What do you currently do if someone is sick for a week or two...or quits entirely? Even if you have 100 people in a certain role, are any of them actually "spare" or are you running at the capacity of 100 people? Commented Apr 21, 2020 at 13:38

5 Answers 5


The scrum part is irrelevant of the specific questions asked.

  1. Does it negatively affect project success? It certainly could. Losing a team member can affect both the duration of the work and the quality of the work if that person brought an expertise that can not be replaced with the remaining members. The smaller your team, the more likely you have an adverse effect. It is not a certain and finite impact most likely but degrees of impact.
  2. ...then what should a manager do? Losing a team member is a normal risk for every project ever undertaken, in progress, or in the future. It is a risk that the manager should have already identified and mitigated. This means the manager should, based on the loss and expected impact, have a plan B in place. This problem gets resolved prospectively or the manager failed to do his/her job.
  3. ...pay for our work...? Depends on your contract terms and conditions and what you're able to deliver. If your capability to produce anything ceases, then obviously your customer shouldn't pay a thing no matter your contract.
  4. ...stated in contract. I have never seen "sickness" called out in a project per se. However, the T&Cs will cover performance, quality, time, deliverables, etc. If the missing person impacts those things, then the contract's T&Cs should indicate what happens.

There are misconceptions around Scrum and team sizes. The first common misconception that I've seen is that Scrum mandates small teams, specifically a Development Team of between 3 and 9 individuals. Scrum contains several concepts that are immutable - "roles, events, artifacts, and rules" - and changing these core concepts would result in something that is not Scrum. The statements that "fewer than three Development Team members" and "having more than nine members" refer to the ranges at which Scrum has been seen to be most optimal. It doesn't mean that Scrum can't be used with a Development Team of one or two or ten or eleven people, but with teams smaller than three or larger than nine, there may be problems where Scrum is either introducing unnecessary overhead and coordination or where the communication is complex and events cannot be completed effectively within their timeboxes.

The key characteristic of a Development Team is that they are cross-functional and have "all the skills as a team necessary to create a product Increment". In addition, Scrum does not recognize titles or sub-teams among Development Team members. Having a "frontend developer", a "backend developer", a "QA engineer", and so on is recognizing titles among members. Consider that someone can have expertise in a particular domain or skill, but the team should strive for distributing the knowledge and the ability to work across all members of the team.

In a situation where the team is reliant on a single individual to provide particular knowledge and skills to deliver, that is something that should be identified as a project risk. As with any risk, it can be avoided, reduced, shared, or retained. The risk can be avoided by increasing the team size to double up on key skills or not taking on work that is too risky. It can be reduced by implementing knowledge sharing, and shorter Sprints may also reduce the chance for unexpected events to occur in the timebox. It can be retained by accepting the risk as it is and moving forward.

  • 1
    Isn’t 3 - 9 members one of the “rules” defined in the Scrum Guide? Commented Apr 22, 2020 at 3:17
  • @PatrickMcElhaney the way it's phrased in the guide isn't a strict "you must have between 3 and 9 members", it's more a strong recommendation. (I originally overstated this in my answer.) Commented Apr 22, 2020 at 7:28
  • 1
    @PatrickMcElhaney Nope - the Scrum Guide only talks about the optimal team size. There are good reasons for it, primarily based on experience. It's one of those things that works for most people most of the time.
    – Thomas Owens
    Commented Apr 22, 2020 at 9:19
  • I still think it’s misleading to call it a “misconception”. The guidelines are there for a reason. Scrum is “difficult to master”. People who are prone to misconceptions (i.e. those who have not little-to-no experience with the roles, events, artifacts, and rules) can benefit from the prescriptive language. Under a doctor’s supervision, it may be safe to take a larger/smaller dose than what’s written on the box. Even in then, your doctor will likely have you start out with the recommended dose. Commented Apr 22, 2020 at 12:09
  • 1
    @PatrickMcElhaney It's not misleading. Many people believe that Scrum mandates or requires a Development Team size of 3-9. Some even go so far as to say if your team is smaller or larger than this, you cannot call what you do Scrum. That is a misconception as Scrum only recommends the team size and does not mandate one
    – Thomas Owens
    Commented Apr 22, 2020 at 13:00

Scrum doesn't blindly suggest "small teams" without qualification and definitely doesn't advocate for having a team so small that one member being sick means that work can't progress. The Scrum guide says (emphasis mine):

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.

In the scenario in your question of only having 3 development team members, you would be right at the lowest sized team that Scrum recommends. There are various ways to reduce the risks you describe from one team member being unavailable, the most obvious ones would be

  1. Cross-skill team members
  2. Increase the team size

Doesn't it negatively affect the project success? Not in any way that wouldn't also apply if you weren't doing Scrum and were bottlenecked on individuals.

If, for example, a backend developer gets sick, then what should we do as a manager? Short term, discuss with the team what the most valuable thing is they can do without that member being present. Long term, work with the team to remove this bottleneck.

Should a customer pay for our work as earlier, despite the fact that we can't produce as much value as when the whole team worked together? - If you can't produce as much value using Scrum as you can when using a different methodology, then either adopt that other methodology or improve how you're doing Scrum.

How this situation should be stated in a contract document? - I wouldn't expect a contract document to get into the level of detail of discussing what happens when a team member is sick.


As you already tagged it, it's (partly) a question about Risk Management, so I'll address that part, since the Scrum part has been addressed in the other good answers.

Obviously, if you decide to have tiny teams, the risk factor of any single team member being unable to work is high.

This would be addressed in your Risk Analysis. I.e. how high is the risk and what you plan on doing to mitigate it. Whether this is added to the contract is a question for your legal team.

As a rule of thumb, we usually pad the schedule taking into account about 20% for sick-leave and vacation. Anything longer than that - or the team member being permanently unavailable - probably falls under the Force Majeure clause, implicit or explicit in contracts.

In conclusion: You never want a situation where a single team member being unavailable for more than a few days would jeopardize the project. You need some contingency plan like having one "jack of all trade" available to take over in an emergency.

I would imagine this is then priced into the contract, though probably not mentioned explicitly.


Mixing DevOps with Scrum helps here, meaning blending responsibilities between developers and operations for greater learning and efficiency. I've seen many projects delayed waiting for an external (and often less motivated) team to take a simple action. Often those admin actions are with an external team such as DBAs out of habit or siloing so moving them to the team is a big help (I recommend the book Phoenix Project, which talks about this as well as CI/CD).

This works especially well if you can hire or grow "full stack developers". Where reasonable, skill sets should overlap. For example while your UI resource may fully understand accessibility, usability and styling fine points, if they get sick a developer should be able to pick up. Moving operations such as database or environment setup to the team will further reduce your risk.

Automated integration tests (ideally combined with continuous delivery) are also very useful here. Done right, they can be written or at least maintained by a developer if you have a dedicated QA person and they get sick. Another approach is to shift that responsibility to developers, though people have strong feelings pro and con there (for example that QA testing is a specific skillset that not everyone can do).

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.