Este post no va a ser otro artículo más sobre qué es el Scrum Planning. Además, vamos a dar por hecho que ya conoces el concepto. De no ser así, y cómo preámbulo, podríamos resumirlo con las siguientes palabras.
Se trata de un evento con time box, donde se va a decidir qué se va a hacer y cómo vamos a hacerlo, en base a un objetivo definido entre todos los miembros del equipo (incluyendo también al Scrum Master).
En este artículo vamos a centrarnos en el “cómo”. En este marco de trabajo, el equipo de desarrollo, debe tener la oportunidad de decidir si un ítem debe dividirse en tareas más pequeñas. Es decir, dejar que ellos se organicen de forma que puedan tener la confianza de que los objetivos, al final del sprint, van a ser alcanzados.
Nuestro equipo trabaja siguiendo principios de eXtreme Programming, tales como CI/CD, TDD, Pair Programming, Automatización y Devops (como actitud).
Teniendo en cuenta estos principios, hemos definido algunas reglas que nos ayudan a la hora de realizar la división del trabajo. Estas reglas son:
- Definimos tareas en base al Definition Of Done (DoD). Para ello, especificamos el DoD a nivel de ítem, tarea técnica y tarea no técnica. Esta práctica nos ayuda a saber cuándo una tarea está realmente lista para ser marcada como Done.
- Hacemos Breaks cuando alguien necesita descansar. Esto es importante, ya que, aunque en la guía Scrum se define este evento como un evento con time box (máximo una hora para Sprints de un mes) nosotros preferimos no tener la presión de un time box. Así que nuestro planning (incluyendo tasking) durará lo que tenga que durar. Para no mermar la calidad, es necesario tomarse ciertos Breaks entre items.
- También definimos las tareas en base al siguiente time box: en un día de trabajo debe estar Done. Puede parecer agresivo, pero esto lo hacemos por varios motivos:
- Nos ayuda a detectar desvíos
- Si una tarea tarda más de un día en moverse a Done, hacemos pair programming (si no lo estuviéramos haciendo ya) o subdividimos en otra tarea.
- Evitamos cuellos de botella: tareas cortas implican reviews cortas. Además si se hacen con pair programming y TDD, no hay necesidad de hacer una pull request (trunk based development).
- No perdemos el foco, bien detallando un edge case que debemos probar en la implementación, o bien poniendo el foco en un refactor que limpie deuda técnica.
- Trabajamos provocando menos bloqueos y conflictos cuando se trabaja en la misma rama. Los cambios se despliegan pronto a master y rápidamente a live/staging.
- También nos apoyamos en el código fuente a la hora de definir tareas, con esta práctica vamos a ir ganando experiencia en cómo abordar la solución.
- Si se trata de un ítem en el que no hay experiencia previa, involucramos a terceras personas veteranas en el planning para que ayuden/aconsejen al equipo.
- Aquellas tareas muy complicadas son marcadas como Pairing mandatory.
Evidentemente no disponemos de una bola de cristal, para ver si las tareas definidas, van a ser suficientes o demasiadas. Sobre todo en las primeras semanas, en las que un equipo Scrum, empieza a funcionar. Sin embargo, sí que aprendemos de cada Sprint, y las reglas mencionadas nos ayudan a conseguir Sprints cada vez más exitosos.
