Como miembros del Equipo Scrum, creamos nuestro Sprint Goal y nos focalizamos al máximo para conseguirlo. No queremos que nada nos distraiga y, claro, las peticiones de stakeholders o departamentos que no casen con ese Sprint Goal o, más ampliamente, con el Product Goal, “van a la cola”. Las “enterramos” en el Product Backlog. Y así un Sprint tras otro. Y otro Sprint. Y otro. El stakeholder de turno se desespera y no entiende esa rigidez. Piensa que sus peticiones nunca serán atendidas. Se frustra con el Equipo Scrum y con el proceso en sí. Protesta sin que nadie le escuche.

Estoy pensando en la gente del departamento de marketing, o en los comerciales, o en los compañeros de soporte al cliente, o en directivos de rango dispar, o en todos aquellos a quienes se les dijo que, gracias a Scrum, gracias a agile, íbamos a trabajar mejor y más rápido. Pero no lo terminan de ver porque, para ellos, el proceso sigue siendo una caja negra y sus solicitudes nunca tienen prioridad.

¿Te suena esta situación?

Seguro que has estado ahí si eres Product Owner, dado que la representación y gestión de los stakeholders te corresponde a ti. Tú serás quien les diga que «sí», que «no» o que «quizás». Si eres “buena gente”, estar siempre diciendo que algo no se va a hacer te resultará poco agradable. En esta tarea, necesitaremos de altas dosis de mano izquierda y puede que también de la ayuda del Scrum Master. Lo último que queremos es desanimar a los stakeholders con nuestro modus operandi. Pretendemos justo lo contrario: crear un producto que maximice el valor para todos ellos. Como mínimo, deberemos explicarles el porqué detrás de las decisiones de producto, que puede estar envuelto en juicios tanto cuantitativos como subjetivos.

Tipos de peticiones procedentes de stakeholders

Para explorar el cómo manejar las peticiones formuladas por stakeholders, me aventuro a enunciar algunos de los tipos de requerimientos más habituales.

Peticiones sin sentido o más o menos pintorescas. El Product Owner debe rechazarlas de plano y asegurarse de que no acceden al Product Backlog. Un «no» a tiempo ahorrará mucha frustración y dolores de cabeza.

Peticiones por aburrimiento. Hay gente en la empresa que se aburre, esto es así. Para salir del sopor, encuentran entretenimiento creando tickets para “los informáticos”, o hasta documentos llenos de especificaciones, etc. De nuevo, practiquemos el deporte de la negación y mantengamos a raya a estos individuos. No estamos para entretener al personal.

Peticiones mega urgentes. El stakeholder presenta su problema como algo que, si no se resuelve de inmediato, nos llevará, irremediablemente, al apocalipsis zombi. Casi siempre, sin embargo, ayudando al stakeholder a poner las cosas en contexto, resultará que el tema no era tan urgente y que puede esperar. Otras veces puede que sí que haya que dar prioridad a lo que el stakeholder plantea o, incluso, seguir el protocolo de disaster recovery.

Funcionalidades de pequeña envergadura pero que pueden marcar la diferencia. Aquí creo que lo recomendable es trabajar con el stakeholder para agrupar estas funcionalidades en un paquete de trabajo de mayor entidad, si es posible, o encontrar huecos para llevarlas a cabo cuanto antes como parte del trabajo de los Sprints, incluso aunque no se relacionen directamente con el Sprint Goal. Estoy pensando, por ejemplo, en pequeñas herramientas o mejoras para el equipo de soporte al cliente.

Funcionalidades de envergadura. Estamos hablando de peticiones de los stakeholders que pueden tener un alto valor potencial y que supondrán un esfuerzo significativo de desarrollo. Puede que obedezcan a un Product Goal propio. Este tipo de historias de usuario tienen que ser priorizadas en su justo momento y encajarse bien dentro de la estrategia de producto. Lo importante en estos casos será que expliquemos bien el roadmap a este stakeholder. Que sepa que, si no podemos abordar su petición ahora, es porque antes tenemos que hacer A, B y C.

El Scrum Master, en su papel de apoyo a la organización, como comentaremos más abajo, puede ayudar a que los stakeholders entiendan cómo relacionarse mejor con los Equipos Scrum. Por ejemplo, será genial evitar las peticiones sin sentido, por aburrimiento y mega urgentes sin fundamento, o reconducirlas como funcionalidades de valor.

Un exceso de noes invita a la reflexión

Si como Product Owner dices que «no» siempre o casi siempre a diversos stakeholders relevantes, o tienes muy clara la visión del producto y los pasos que estás dando o igual es momento para la reflexión. En especial si los stakeholders tienen un conocimiento profundo del sector o están en contacto estrecho con el cliente. ¿Qué te hace pensar que estás fijando bien las prioridades de producto si dejamos a un lado estas voces?

Ojo, no digo que los stakeholders nos hagan el Product Backlog. Ni mucho menos. Tenemos que tener nuestro propio plan, y este ha de contemplar, en mayor o menor medida, el dar respuestas a los problemas enunciados por aquellos. O fundamentar bien por qué no se abordan determinados desarrollos. Si no lo hacemos, más temprano que tarde, alguno terminará “pidiendo nuestra cabeza” o, cuando menos, cuestionando el proceso de toma de decisiones.

El Scrum Master y el Equipo Scrum han de colaborar con los stakeholders

La nueva Guía Scrum 2020 parece quitar énfasis al papel del Product Owner como gestor de stakeholders para hacer hincapié en que el Equipo en su conjunto, incluido el Scrum Master, también tienen que arrimar el hombro.

En concreto, la Guía señala que el Equipo Scrum es responsable de todas las actividades relacionadas con el producto, entre las que se encuentra, como no, la colaboración con los stakeholders. Respecto al Scrum Master, indica que debe facilitar la colaboración entre Product Owner y stakeholders cuando se solicite o necesite, y que ha de ayudar a los stakeholders a entender el empirismo en entornos complejos, así como eliminar barreras entre stakeholders y los Equipos Scrum.

Por tanto, el tener en consideración y colaborar estrechamente con los stakeholders no es solo responsabilidad exclusiva del Product Owner, sino que es, ante todo, un deporte de equipo. Queremos que los stakeholders sean eso, colaboradores estrechos, no personas que acaben hastiadas por el uso de Scrum.