How small can a scrum team before it's no longer effective? Are there diminishing returns or hard limits on team size before you should abandon scrum?
The answer to this can be found in the Scrum Guide.
There are three roles in Scrum: Product Owner, Development Team, and Scrum Master. Although not explicitly stated in the Scrum Guide, it's recommended that the Product Owner and Scrum Master are different people, since some of their responsibilities may be at odds at certain points in time. This alone implies that you need at least 3 people to conduct Scrum.
However, the section on the Development Team adds additional guidance. A Development Team that is smaller than 3 people doesn't take full advantage of the ceremonies and artifacts defined by Scrum. At the same time, a Development Team with more than 9 people requires more coordination than Scrum allows for. Therefore, a Development Team should be between 3 and 9 people.
The smallest feasible Scrum Team is 4 people: a Product Owner and a Development Team of 3 people, where one person from the Development Team is also a Scrum Master. The largest possible Scrum Team is 11 people: a Product Owner, a Scrum Master, and a Development Team of 9 people.
As presented by the creators of Scrum - if you have 3 or fewer people, you should be looking at something other than Scrum to manage your project.
Zero is not enough.
Even if you are the single developer in a company, it's not unreasonable to follow the scrum procedures to organise your work. You write down tasks into a backlog, every two weeks you pick tasks from the backlog and put them into a sprint, and at the end of the two weeks you see more or less proudly which of these tasks you have achieved.
It may take a bit more focus. When you don't have two developers, you should still review your own code and accept it as finished only when it is reviewed, and if you don't have a dedicated tester, you should still test your code and accepted it only after it has been tested.
If the scrum guide doesn't like fewer than three developers, and your company refuses to pay three or even two developer salaries, then that shouldn't stop you from using scrum.
It doesn't have to be all-or-nothing. Scrum is not a set of scriptures that have to be adhered to religiously. Some parts of Scum become less important as a team becomes smaller, others make sense and can be adapted even for a single developer.
I'd say that the following aspects are good even when you're a lone developer working on a pet project:
- A prioritised product backlog
- User stories
- Timeboxed sprints with a goal and a releasable result
- Sprint planning and retrospective (these can be very short, but still provide a useful focus)
As soon as you are working for someone, it becomes useful to have:
- A product owner
- A sprint review
And I'd say that even with 2 developers, a (very quick) daily Scrum can help to coordinate.
The Scrum Master role really only makes sense with 3 or more developers, to have someone be in charge of organizing the now more complex meetings, mediate disagreements and focus on removing impediments.
The Scrum Guide gives this guidance on team size:
Development Team Size 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 manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog. (http://www.scrumguides.org/scrum-guide.html)
I personally think that below 5 is starting to lose team characteristics.