¿Por qué el Equipo Scrum debe tener 10 miembros o menos?


La Guía Scrum 2020 indica que el Equipo Scrum, “típicamente”, se compone por 10 personas o menos. [La Guía de 2017 señalaba que el Equipo de Desarrollo debía componerse por entre tres y nueve personas, sin contar con el Scrum Master y el Product Owner, a menos de que estos también realizaran tareas de desarrollo durante el Sprint. Dicho de otra manera, el Equipo Scrum podía integrarse por un máximo de once profesionales. Con la actualización de 2020, la Guía es menos prescriptiva y precisa en cuanto al número de miembros del Equipo Scrum, al tiempo que elimina la mención al Equipo de Desarrollo].


¿De dónde sale este número “mágico” para establecer el tamaño deseable del Equipo Scrum?

No es arbitrario. Ken Schwaber y Jeff Sutherland, creadores de Scrum, se basan en la investigación empírica al respecto. El todopoderoso Mike Cohn lo muestra en un gráfico como el de abajo, que recoge el tiempo invertido en completar proyectos de software equivalentes, dependiendo del número de integrantes del Equipo.

Con menos de tres personas, será difícil que el Equipo Scrum cuente con todas las habilidades necesarias para producir el Incremento, a saber: diseño UX/UI, programación back-end/front-end, testing, documentación y un largo etcétera, según el producto de que se trate. A su vez, si el Equipo se compone por una o dos personas, las necesidades de comunicación y coordinación serán mínimas. No obstante, al menos teóricamente, podemos hacer Scrum con tan solo dos personas.

He de decir que uno de los mejores Equipos de los que he formado parte lo formábamos tres personas. Eso sí, éramos “tres bestias”, en modo “Super Saiyan” continuo. Siempre que el Equipo sea multifuncional, mi máxima es que, cuanto más pequeño, mejor.


A partir de 10 miembros, cuidado. Las exigencias de coordinación se disparan y empezamos a notar una pérdida importante de productividad, como muestra el gráfico. Añadir miembros al Equipo solo empeora las cosas y hace que tardemos más en entregar. Lo conveniente será “partir” el Equipo y habilitar mecanismos de coordinación para esos dos o “n” Equipos Scrum (que nos llevará potencialmente a modelos de “escalado”). Este es un clásico en empresas en crecimiento, donde a esta tensión se añade la contratación de profesionales que son nuevos en la organización.

La idea expresada en el gráfico es contraria a lo que muchos puedan creer. Cuando empecé en esto del software, iluso de mí, pensaba que los desarrolladores se añadían “al peso”, que, cuantos más, mejor. A lo largo de los años he tenido que combatir esta misma falacia. Recuerdo una situación muy divertida en la que el CFO de una agencia digital bastante grande quería sumar otros veinte desarrolladores al proyecto para acortar los plazos de lanzamiento de la primera versión; y yo le decía que no, que por favor nos diera a uno solo, al mejor que tuviera 😊


¿Sigo haciendo Scrum si mi Equipo tiene más de 10 personas?

Sergio, y, si en mi Equipo Scrum somos 15, ¿significa que ya no estamos haciendo Scrum? Recientemente un Scrum Master me planteaba esta situación, y me decía que ellos estaban “adaptando” el framework a sus circunstancias y que, si dividían al Equipo en dos como yo sugería, ya dejaban de ser multifuncionales.

En mi opinión, si en efecto esta es la única forma de preservar la multifuncionalidad, es posible “aceptar «pulpo» como animal de compañía”, a corto plazo o durante varios Sprints. No obstante, en este caso en concreto, el objetivo debería ser resolver las carencias en habilidades que nos impiden pasar a un esquema de dos Equipos. Puede ser que tu situación sea la excepción que cumple la regla y que vuestra productividad como Equipo sea mayor con 15 personas que con dos Equipos de seis y siete desarrolladores, pero lo dudo mucho. Prefiero no reinventar la rueda.


Bienvenidos al maravilloso mundo de las habilidades en forma de “T”

A fin de aumentar el grado de multifuncionalidad del Equipo Scrum, el Scrum Master ha de procurar el ensanchamiento del abanico de habilidades de sus miembros, es decir, fomentar las habilidades de forma de “T”, de las que que hablamos en este post.


Imagen de portada: Daily Sprint Meeting by Klean Denmark

Cuando estés listo, podemos ayudarte de 3 formas:

  1. 1. Únete a nuestra Newsletter, Líderes de Producto: recibe contenidos exclusivos sobre Agile y Product Management.
  2. 2. Apúntate a una de nuestras formaciones: cursos intensivos para Product Owners/Managers y Scrum Master/Agile Coaches, en directo e impartidos por nuestros especialistas.
  3. 3. ¿Quieres formar a tu equipo? Hacemos formaciones “privadas” para empresas, con las que transformar vuestra forma de trabajar. Somos especialistas en Scrum y Product Management.
Comparte este post

Publicado por Sergio Rodríguez

Especialista en producto y Professional Scrum Trainer acreditado por Scrum.org. He sido Product Manager, Head of Product y consultor de producto en empresas como Liftshare, Cardmarket o Wave.

Subscríbete a nuestro Newsletter

Únete a cientos de lectores de Líderes de Producto para recibir historias, consejos y recursos sobre Product Management y Scrum.