Hola a todos, este es uno de los post que hace tiempo tenía
pendiente por escribir y por fin se alinearon los astros y pude escribirlo.
Empecemos, según la Guía Oficial de Scrum (1) el planning
consta de dos partes:
- Tema Uno: ¿Qué puede hacerse en este Sprint?
(conocido como “El Qué”): El cual consiste en la identificación del Objetivo
del Sprint y la lista de ítems de backlog que hacen parte del producto que si
se completan lograrían el Objetivo del Sprint
- Tema Dos: ¿Cómo se conseguirá completar el
trabajo seleccionado? (conocido como “El Cómo”): El cual consiste que el Equipo de Desarrollo decide cómo
construirá esta funcionalidad para formar un Incremento de producto “Terminado” durante el
Sprint que cumpla con el Objetivo y contenga los ítems seleccionados en el paso
anterior más el plan para terminarlos.
Adicionalmente, para el tema 2 dice claramente:
“El Equipo de Desarrollo por lo
general comienza diseñando el sistema y el trabajo necesario para convertir la
Lista de Producto en un Incremento de producto funcional. El trabajo podría ser
de tamaño o esfuerzo estimado variables. Sin embargo, durante la Planificación
del Sprint se planifica suficiente trabajo como para que el Equipo de
Desarrollo pueda hacer una proyección de lo que cree que puede completar en el
Sprint que comienza. Para el final de esta reunión, el trabajo planificado por el Equipo de Desarrollo para los primeros
días del Sprint es descompuesto en unidades de un día o menos.” (Esto último
es conocido en el mundo de Scrum con el Tasking, o la descomposición en tareas
de los ítems de backlog - como la palabra misma lo sugiere-)
Aquí vemos dos cosas:
- Se sugiere que el trabajo se descomponga de
forma gradual en unidades, o sea, NO SE DESCOMPONGA TODO A PRIORI en el planning del sprint (ya sea por timebox
o conveniencia), sino que se identifique claramente las tareas próximas de lo próximo
que se va a hacer y luego se descomponga el resto cuando estemos cercanos a
construirlo (esto es conocido en el mundo de gerencia de proyectos como
Planeación Gradual o Rolling Wave Planning – la cual empleamos nosotros ampliamente
en el mundo ágil –). Acá quiero hacer una precisión, nunca lo he hecho así,
siempre sugiero o hago la descomposición de todas las historias de usuario en
tareas durante el planning –y nos ha ido
bien –, haré el experimento y lo compartiré.
- Lo segundo que me parece MUY PODEROSO es
descomponer el trabajo en unidades de UN DÍA O MENOS.
Y es en esto último donde uno dice: “Claro, tiene sentido,
de esa manera todos los días se finalizará algo y de esa forma se sentirá el progreso y se identificarán fácil los impedimentos y puntos de atasque".
Basado en lo anterior vienen los siguientes puntos
Cómo he trabajado el
tasking o cómo lo he visto
Este ejercicio de descomponer las historias de usuario en tareas
de un día o menos (léase Tasking), y me he encontrado con equipos que han
decidido manejarlo de diferente manera, el punto no es discutir cuál es la
mejor, es mejor pensar, con cual se siente más cómodo mi equipo, adicionalmente
puede que lo hagan de una forma durante un tiempo y luego cambien a otra
(recordemos el principio básico de la gestión empírica “Inspección y
Adaptación”), volviendo al tema las formas de tasking que he observado son:
Forma de tasking
|
Observación
|
·
Dividir la historia de usuario en tareas de
tamaños de unidades entre 1 y 8, así: 1h, 2h, 3h, 4h, 5h, 6h, 7h, 8h
|
La verdad esta no me gusta, lo que he encontrado es que no somos
buenos estimando en esta forma, pues la precisión aun a nivel de tareas aún
es baja en desarrollo de software, adicional abre el espacio a la
microgestión que limita al equipo y no permite que el equipo aprenda.
|
·
Dividir historia de usuario en las tareas de
tamaños de 2h, 4h, 6h, 8h
|
Esta forma me gusta, brinda amortiguación si se falla en la
estimación.
|
·
Dividir la historia de usuario en las tareas
de tamaños de 2h, 4h, 8h
|
Esta es la que más me gusta, por la misma razón de la anterior,
adicionalmente permite que falles, aprender, mejorar, da más libertad al
equipo.
|
·
Dividir la historia de usuario en tareas sin
horas pero garantizando que cada tarea es menor a un día
|
Esta forma la he visto en equipos muy maduros en los cuales la
confianza y transparencia son una constante presente en su día a día.
|
Ahora el Super Tip
Este tip me lo enseño Silvia Lozano (
@sila_zenufana) – y me ha servido
montones con los equipos que he tenido la suerte de estar y acompañar –, quien
me sugirió en el tablero kanban poner
UN
PUNTO por cada día que permanece la tarea en la zona del WIP (“Work In
Progress” o “Work in Process”) de esta manera se identificará que
una tarea requiere ayuda si tiene más de
DOS PUNTOS, pues recordemos que como tenemos por regla (o sugerencia) que
las tareas no deben durar más de un día, si las tareas en el tablero kanban
tienen
DOS PUNTOS O MÁS significa que:
- Existe un posible impedimento
- Existe una posible dificultad en desarrollar la tarea
- Existe una posible falta de foco o de habilidad por parte de desarrollador que esta trabajando en ella
- Se estimó de una forma muy optimista o con falta de conocimiento del real tamaño
- Existe un desbordamiento de alcance
- O es un punto de mejora para discutir en la retrospectiva
En cualquiera de los anteriores es un punto donde tanto
Scrum Master como Equipo observan un punto en el que hay que hacer intervención.
OJO: Lo anterior funciona muy bien si tenemos la buena práctica
que siempre haya en el tablero una tarea por persona del equipo – recordemos que
solo somos capaces de hacer una cosa a la vez, o sea en el WIP una persona no
puede tener más de dos tareas – o sea,
que en el WIP si el equipo tiene 4 integrantes a lo sumo existirán 4 post-it (o
pósit (2)) a la vez que representan una tarea por cada uno de ellos.
Cerrando
Espero que lo compartido sea de utilidad en tu equipo
Scrum, y para terminar tres preguntas
- ¿Cuándo fue la última vez que leíste la guía oficial de Scrum?
- ¿Qué descubrimiento has hecho?
- ¿los puedes compartir?
Bienvenida la retroalimentación y sus comentarios.
Saludos ágiles
Jorge Abad
Notas, Aclaraciones, Comentarios y Referencias
- La que se encuentra en Scrumguides.org
- Es correcta esta forma de escribirlo, la RAE lo permite ver acá Pósit http://dle.rae.es/?id=TnfXVsj
