Scrum 101: guía práctica para aumentar la productividad de tus equipos

11 min readFeb 8, 2022

8 febrero 2022

Lo sabemos: este año tu equipo se ha propuesto ser más productivo, eficaz y preciso, aumentado la calidad de los entregables y acabados. Pero sabemos también que, aunque pueda parecer un objetivo fácil, no lo es tanto. En Good Rebels, llevamos años dando libertad a nuestros equipos para probar las metodologías y formas de trabajo que más se ajusten a sus necesidades y nos ayuden a mejorar en todos los ámbitos. Y, recientemente, la joya de la corona son las metodologías ágiles, que ya hemos implementado en muchos de nuestros equipos.

Pero este post no se va a sumar al montón de contenidos que describen las metodologías ágiles porque, como bien dice el refrán, del dicho al hecho hay un trecho. Esta vez queremos llevar el discurso a la práctica y contaros cómo nosotras (y más específicamente, algunos de nuestros equipos de diseño) trabajamos utilizando frameworks o marcos de trabajo ágiles, que nos dibujan el camino a seguir a partir de una serie de técnicas y prácticas definidas.

Los frameworks permiten homogeneizar procesos entre los equipos y con el cliente y trabajar de una forma más eficiente, incrementando así la productividad, minimizando errores y mejorando el funcionamiento del equipo. Por decirlo de otra forma, hacen la vida más fácil a quienes trabajamos en proyectos donde intervienen muchos actores, como es el caso de los productos digitales. La elección de éstos dependerá del proyecto, del equipo y de sus necesidades.

Scrum es uno de estos frameworks y queremos contarte algunas de las claves para incorporarlo con éxito en tus procesos, repasando aspectos clave como qué son las historias de usuario, cuáles son algunas de las ceremonias habituales y qué importancia tiene una correcta planificación.

Por qué Scrum

Antes de empezar, nos gustaría destacar algunas de las ventajas de trabajar en Scrum:

Cooperación. La comunicación es constante entre todos los stakeholders del proyecto, de forma que hay un alineamiento entre el cliente y los equipos. Esto supone un gran ahorro de tiempo y una buena gestión de las expectativas.
Productividad. Al mejorar la comunicación entre el cliente y los diferentes equipos de trabajo conseguimos aumentar la productividad de todas las partes implicadas.
El cliente es un miembro más del equipo de trabajo. El cliente está presente durante todo el proceso, trabajando conjuntamente hacia un mismo objetivo, alineados, sin sorpresas y con entregas pautadas. Esto da como resultado un cliente satisfecho que tiene en mente lo que se está haciendo prácticamente cada día.
Flexibilidad. Al trabajar en periodos de una duración concreta, podemos evaluar en tiempo real las prioridades que tiene el producto según el mercado o los usuarios. Además, es importante asumir que los cambios son naturales en cualquier producto y gracias al trabajo en Scrum es mucho más sencillo planear una iteración, eliminar una funcionalidad o proponer una nueva.

Los sprints y las historias de usuario en Scrum

No paramos de repetir que nuestros proyectos involucran a varios equipos con distinto expertise, además de a un cliente al que hay que satisfacer y que quiere estar al tanto de todo. La planificación y la organización son primordiales, y por ello necesitamos perfiles concretos que nos guíen y nos marquen el camino a seguir. Estos perfiles estratégicos se encargan de definir los objetivos del proyecto y las futuras funcionalidades, de planificar el tiempo que lleva cada tarea, de valorar la carga de trabajo de cada equipo…

Todo esto no puede planificarse a largo plazo. Hablamos de productos digitales que están en constante cambio y cuyo diseño y desarrollo puede durar años. Además, es frecuente incorporar mejoras y nuevas funcionalidades que a menudo (si el producto ya está en el mercado) responden a críticas o peticiones de los usuarios. Podríamos decir que durante el proceso de diseño y desarrollo de un producto digital nos enfrentamos a un sinfín de obstáculos, pero en Good Rebels preferimos verlos como oportunidades de mejora.

Por ello, no se entiende Scrum sin los sprints. Se trata de mini-proyectos con una duración fija, generalmente de dos semanas, para aportar más valor al producto. Cuando se empieza un sprint, lo ideal es establecer un objetivo tangible, que se entregará completado al finalizar el sprint de una forma u otra, dependiendo del equipo que lo trabaje.

Este es un ejemplo de cómo puede definirse un sprint:

Para definir estos objetivos hacemos uso de las historias de usuario o user stories (US), necesarias para el desarrollo de un producto digital.

¿Qué es una historia de usuario?

Las historias de usuario son descripciones de una funcionalidad, definen una función del software que estamos desarrollando con un lenguaje sencillo, próximo al usuario y al cliente.

Una historia de usuario ha de ser precisa para que todos los miembros del equipo comprendan su alcance. Así, se busca garantizar una mejor estimación de los tiempos, valorar qué otras historias de usuario se ven afectadas por ella y establecer su prioridad. Se trata de una de las unidades en la que se divide el trabajo, una necesidad a la que hay que dar respuesta dentro de cada sprint.

¿Quién crea las historias de usuario?

Cualquier persona implicada en el proyecto puede escribir una historia de usuario, dándole así más valor y pluralidad. Si centralizamos la creación de las historias de usuario en un único responsable, podríamos dejar a un lado el punto de vista del usuario y depender constantemente de la visión de este perfil.

Ahora bien, aunque todos los miembros del equipo podemos redactarlas, el Product Owner es el perfil encargado de su organización y priorización.

¿Qué estructura tienen?

Existe una estructura común extendida sobre las historias de usuario:

Como [usuario] + Quiero [intención] + Para [objetivo, logro]

Pongamos un ejemplo para aclararlo, siempre teniendo en cuenta que el lenguaje que tenemos que utilizar es el del usuario, no el del equipo de expertos que están diseñando y desarrollando el producto. Imaginemos que tenemos una frutería y queremos mejorar las ventas a través de nuestra página web:

Como [frutera] quiero [aumentar las ventas online] para [obtener un mayor beneficio].

Utilizando esta estructura es más sencillo saber qué es lo que realmente quiere el usuario y cómo podemos mejorar su experiencia. Además, nos permiten un mayor acercamiento al cliente, ya que puede saber en todo momento qué se está construyendo y si está a la altura de sus expectativas.

Algunas ceremonias de Scrum

Como sucede en cualquier proyecto, todos los equipos estamos conectados por alguna herramienta de gestión de proyectos, email o cualquier otra plataforma de comunicación.

Ahora bien, para llevar a cabo realmente un proyecto en Scrum son necesarios una serie de ritos, a los que también podemos llamar ceremonias, eventos o rituales, que nos permiten mejorar la comunicación entre todos los equipos, incluido el cliente, y saber en todo momento en qué punto nos encontramos.

Algunos de los ritos más importantes son los siguientes:

Sprint Planning. Se realiza antes de comenzar un sprint, aproximadamente cada dos semanas. En él, se reúnen todos los equipos, incluido el cliente, para decidir los objetivos del sprint y qué historias de usuario van a abordarse. Las historias de usuario que están esperando a entrar en un sprint están recogidas en un listado llamado Product Backlog.
Grooming. Se realiza cada 1 ó 2 semanas. En él participan todos los equipos, y el principal objetivo es refinar el Product Backlog, es decir, ver qué historias de usuario hay listadas, priorizarlas, definirlas más o incluso eliminarlas.
Daily. Son reuniones diarias que cada equipo celebra internamente y por separado. Su duración es de 15 minutos y el objetivo es que todas sepamos qué hicimos el día anterior, qué vamos a hacer hoy y qué bloqueos tenemos. Si aparece algún bloqueo, normalmente se agenda otra reunión con alguna persona del equipo para intentar resolverlo.
Sprint Review. Lo más habitual es que, cuando termina el sprint, el equipo de desarrollo y cliente se reúnan para revisar qué se ha desarrollado y terminado durante (normalmente) las 2 semanas. En este rito ya se empieza a planear el siguiente sprint, ya que se conoce qué cosas han quedado pendientes, cuáles se podrían mejorar o qué dificultades se han encontrado.

Planificación y herramientas

Hemos insistido mucho en este aspecto: en este tipo de proyectos se juntan muchas variables y una de ellas es que trabajamos varios equipos de distintas disciplinas como diseño y desarrollo. Ambos tenemos tiempos y formas de trabajar diferentes, y para gestionar esta dicotomía en ocasiones adoptamos un framework específico, el Dual-Track Scrum.

Si trabajamos en Scrum, una de las estrategias más sencillas para facilitarnos el trabajo es utilizar tableros o boards separados donde se recogen las historias de usuario y otras tareas. Esto nos permite una correcta planificación y organización, salvando parte de la dicotomía que mencionábamos. A continuación veremos a modo de ejemplo, dos de las herramientas de gestión de proyectos que utilizamos en el equipo de diseño de Good Rebels, aunque empleamos otras igual de válidas.

Teamwork

En esta herramienta de gestión participamos todos los equipos implicados en el producto digital, incluido el cliente, que además de utilizarla para tener una visión general del proyecto y hacer un seguimiento del mismo, puede participar activamente.

Aquí se estructura cada sprint, se crean las historias de usuario que se asignan a un equipo o persona concreta, se estima el tiempo necesario para cada una de ellas e incluso se imputan horas de trabajo.

Para estructurar cada sprint de una forma visual, se monta un tablero agile, también conocido como Sprint board, organizado por columnas. En ellas se recogen las historias de usuario que, como podemos ver en la imagen, vienen representadas en forma de cards o tarjetas.

Normalmente, la columna en la que está recogida la historia de usuario nos indica qué equipo es el encargado de llevarla a cabo.

Columnas donde participa el equipo de desarrollo:

To do. Recoge las historias de usuario que se tienen que llevar a cabo en este sprint.
Doing. Recoge las historias de usuario que se están desarrollando en ese momento.
Resolved. Recoge las historias de usuario desarrolladas, listas para revisión.
Code Review. Recoge las historias de usuario en revisión. El equipo ha de revisar el código y mejorar su calidad en caso de ser necesario.
Blocked. Recoge las historias de usuario bloqueadas por errores, por falta de contexto, por temas legales…
Ready to test. Recoge las historias de usuario en las que el código cumple con los estándares y están a la espera de que el equipo de QA (calidad) las revise.
Testing. Antes de que el usuario vea las nuevas funcionalidades, cambios o actualizaciones, se prueban en un entorno ficticio con el objetivo de evitar futuros errores.
Done. Historias de usuario completadas. Los usuarios ya pueden disfrutar la nueva funcionalidad, cambio o actualización. Podríamos decir que este es el final del trabajo del equipo de desarrollo.

Columnas donde participa el equipo de diseño:

DoR (Definition of ready). Recoge las historias de usuario que ya han sido diseñadas, validadas y estimadas. Están preparadas para desarrollarse.
Grooming. Recoge las historias de usuario que van a ser revisadas, validadas y estimadas. Es habitual valorar si formarán parte del siguiente sprint.
Doing (GR). Recoge las historias de usuario que se están diseñando.
Diseños y flujos. Recoge las historias de usuario que van a ser diseñadas a futuro, sin prioridad específica.

El orden lógico sería que estas últimas columnas (Diseños y flujos, Doing (GR), Grooming y DoR) estuvieran colocadas las primeras, ya que antes de que una historia de usuario pase a desarrollo ha de estar diseñada, revisada y validada. Ahora bien, este tablero está enfocado al trabajo de desarrollo, por lo que está priorizado y organizado para dicho equipo.

Trello

Al igual que Teamwork, se trata de una herramienta de gestión pero, en este caso, solo la utilizamos el equipo de diseño. Aquí es donde nos organizamos internamente. La lead del equipo, que tiene una función muy importante en lo referente a la gestión y a la organización, revisa todas las historias de usuario que tenemos asignadas en el tablero de Teamwork para posteriormente trasladarlas a Trello y transformarlas a un lenguaje más cercano al diseño.

Por muy buena que sea la comunicación con el equipo de desarrollo, tenemos que adaptar las historias de usuario a nuestra forma de trabajar, entenderlas, organizarlas según nuestros criterios, adjuntar referencias, añadir comentarios entre nosotras… También estructuramos Trello por columnas en un tablero agile, aunque de una forma diferente:

Docs. Documentos que nos ayudan en el día a día: funcionales, credenciales de acceso, instrucciones…
Backlog. Equivalente a Diseños y flujos en el tablero de Teamwork, recoge las historias de usuario que van a ser diseñadas a futuro, sin prioridad específica.
To do. Recoge las historias de usuario que tenemos que diseñar.
Doing. Recoge las historias de usuario que estamos diseñando en ese momento.
To review. Recoge las historias de usuario que ya hemos diseñado y tenemos que revisar con cliente y/o desarrollo para validarlas.
Blocked. Al igual que en el tablero de Teamwork, recoge las historias de usuario bloqueadas por errores, por falta de contexto, por temas legales…
Grooming. Al igual que en el tablero de Teamwork, recoge las historias de usuario que van a ser revisadas, validadas y estimadas. Es habitual valorar si formarán parte del siguiente sprint.
DoR. Al igual que en el tablero de Teamwork, recoge las historias de usuario que ya han sido diseñadas, validadas y estimadas. Están preparadas para desarrollarse.
Implemented. Equivalente a Done en el tablero de Teamwork, son historias de usuario completadas, los usuarios ya pueden disfrutar la nueva funcionalidad, cambio o actualización.
Mastered. Recoge las historias de usuario que ya hemos integrado en un documento interno llamado Master. Ésta nos permite tener una fotografía del estado actual del producto. Es el último paso para nosotras como equipo de diseño.

Gracias a esta estructura sabemos en todo momento quién está trabajando en cada tarea, si se ha dado el visto bueno por parte del equipo de desarrollo y/o el cliente, si se ha empezado a desarrollar o si ya está en funcionamiento.

Más allá del diseño y desarrollo de producto

Scrum es una metodología que facilita la gestión de equipos multidisciplinares, la distribución de las tareas en el tiempo y la gestión y supervisión por parte del cliente. Pero, llegados a este punto quizás te preguntes si, a pesar de que nació como framework para el desarrollo de software y su uso esté muy extendido en proyectos de diseño, podríamos aplicarlo a otros proyectos.

La respuesta en sí: en Good Rebels utilizamos esta metodología en distintas áreas, en mayor o menor medida, dependiendo siempre de la tipología de los proyectos. Y aunque requiere de un análisis pormenorizado de las funciones del proyecto y de la implementación, nadie nos prohíbe experimentar, coger de aquí y de allá y ver qué pasa.
Puede que haya proyectos en los que podamos usar Scrum al 100%, otros al 50%, otros al 10% o incluso personalizarlo. Es cuestión de tantear, de adaptarse al framework y que, de igual manera, el framework se adapte a nuestro proyecto.

¡Gracias por leernos! Si quieres saber más… ¿Hablamos?