Existe mucha infografía e información acerca de la diferencia entre el Scrum board y el Kanban board. El Scrum Board es una herramienta que realmente no existe en Scrum pero que muchos equipos utilizan para mejorar su capacidad de organización. ¿En qué consiste el Scrum Board?
Tableros
Gracias a Agile y su expansión, se han desarrollado muchas prácticas complementarias a Scrum o Kanban. Por ejemplo: puntos de historias, OKR, Management 3.0… Una de las herramientas favorita es el visual management. La gestión visual nos ayuda a entender mejor el contexto y alinearnos. Sin embargo, Scrum apenas habla del visual management. Cosa diferente ocurre en Kanban donde sí que es cierto que la primera práctica es la visualización y se recomienda algún tipo de tablero físico.
Ahora bien, a raíz de la subida del teletrabajo provocada por la pandemia muchos equipos están optando por un visual management basado en herramientas digitales. Personalmente, creo que herramientas como Jira o Azure no son las mejores para esta práctica. Sin embargo, herramientas como Mural o Miró sí que tiene mucho sentido a la hora de poder hacer una gestión visual.
Aun así, Scrum tiene una tendencia a evitar prescribir ningún tipo de práctica. Scrum no dice cómo medir valor, plantear un plan estratégico o tomar requisitos. Por tanto , tampoco va a decir cómo enfocar tú tablero de trabajo.
Si vemos algún tipo de infografía relacionada con el Scrum board realmente nos están tratando de engañar.
De dónde viene el Scrum Board
Scrum propone tres artefactos: Product Backlog, Sprint Backlog e Incremento. El tercero suele ser el más etéreo pero el que mayor relevancia tiene ya que representa todo el trabajo que hemos realizado hasta ahora y por el cual podemos medir el valor. El Product Backlog es raro que se apoye en una herramienta visual, algo que sí es habitual en el Sprint Backlog.
El Product Backlog suele ser digital porque el Product Owner suele moverse mucho para hablar con interesados. Mientras que el equipo suele vivir en un sitio fijo donde usar tableros físicos.
Dado que muchos equipos utilizan un tablero visual para organizar el Sprint Backlog se ha generado mucha confusión entre este tablero y el que suele utilizar en Kanban. Recordemos que Kanban viene del mundo industrial donde tener tableros con postits era más realista que hoy en día muchos equipos de software donde no trabajan físicamente juntos.
Características del Scrum Board
Si decidimos tener un tablero para organizar el Sprint hay recomendaciones que debemos de tener en cuenta:
- Debe ser una herramienta de los developers y gestionada y evolucionada por ellos
- No existe un tablero mejor que otro, prueba y experimenta
- Un tablero debe tener como vida el tiempo del Sprint
- Debemos debemos tener una política de actualización del tablero puede ser cada día puede ser cada vez que una tarea termina etc
- Utiliza la retrospectiva para evolucionar el tablero y detectar punto de mejora
Estas son algunas recomendaciones pero recordemos que Scrum no prescribe esta práctica y por tanto es voluntaria.
Product backlog con tablero
En mi opinión suele gestionar pocas veces el Product Backlog con herramientas visuales pero sí que he utilizado para hacer estrategia a largo plazo.
El motivo es que la estrategia a largo plazo sí que suelo validarla bastante dado que muchas veces estamos hablando de features que ni siquiera están analizadas.
Por tanto, el tener un tablero fisico a largo plazo nos ayuda a tener una conversación con stakeholders y gestionar bien las expectativas. No es obligatorio en Scrum esta práctica pero a mí me ayuda bastante y mejorar la entrega de valor.
Y tú, ¿tienes un Scrum Board?
