TECNICAS SCRUM:
ARTICULO OBTENIDO POR SIMON FLOSSMAN:
RETOS EN LA PLANIFICACION
DEL SPRINT
¿La
planificación del sprint es como un maratón? Haga estas 3 preguntas críticas
para perfeccionar el Product Backlog con anticipación y así acortar la
planificación del Sprint
- Contacto Simon Flossmann
- Twitter para Simon Flossmann
- LinkedIn para Simon Flossmann
10 de junio
de 2024
Clasificado
con 1 estrellas de 1
0 de 0
calificaciones
¿Cuánto tiempo lleva planificar un sprint en tu equipo?
Si tu respuesta es “menos de cuatro horas”, lamentablemente esta
publicación no es para ti.
Para todos los demás: existe una buena posibilidad de que
podamos acortar significativamente la planificación del sprint mejorando el
refinamiento de la cartera de productos.
¿Cómo se puede mejorar el refinamiento de la
cartera de productos?
Hacer preguntas críticas puede mejorar el refinamiento de la
cartera de productos. Me gustaría presentar tres de esas preguntas en este
artículo:
- ¿Podemos
completar esta entrada en un sprint?
- ¿Cómo
podemos dividir esta entrada para terminar antes?
- ¿Cómo
podemos recopilar comentarios de los usuarios antes?
Antes de explicar las preguntas en detalle, me gustaría explicar
por qué las considero “críticas” y por qué este artículo está destinado a
equipos que dedican más de cuatro horas a la planificación del Sprint.
Las tres preguntas son fundamentales para ofrecer valor antes:
una promesa que las empresas quieren cumplir cuando utilizan Scrum. También son
fundamentales para reducir el tiempo que el equipo dedica a la planificación
del sprint. Planificar demasiado de golpe es un desperdicio de la capacidad del
equipo. La Guía Scrum advierte contra esto con esta regla:
“La planificación de sprints está limitada a un máximo de ocho
horas para un sprint de un mes. Con sprints más cortos, el evento es
correspondientemente más corto”.
En resumen: un equipo Scrum no debería dedicar más de ocho horas
a planificar un sprint.
Esto no significa que los equipos Scrum no puedan planificar su
trabajo con más frecuencia en sprints o que no deban reprogramarlo
periódicamente a medida que surjan nuevos conocimientos. Y ciertamente no
significa que los equipos Scrum deban abandonar su planificación a largo plazo
con las partes interesadas en la Revisión del Sprint.
Simplemente significa:
Después de más de ocho horas de planificar cómo implementar
realmente una función, es más valioso comenzar a implementarla y resolver
cualquier problema cuando realmente surja. En mi experiencia, cuatro horas de
planificación de sprints son un buen equilibrio entre concentración y
profundidad del contenido. Centrarse en formular un objetivo de sprint que
proporcione una estrella guía para todo el trabajo del sprint. Al mismo tiempo,
las cuatro horas proporcionan tiempo suficiente para planificar los detalles de
la implementación de la entrada del backlog del producto que se implementará
primero.
Ahora a las preguntas: haga estas preguntas antes de la
planificación del Sprint para activar el refinamiento del Product Backlog.
Luego podrá reconocer el éxito de su iniciativa por la duración de la
planificación del sprint.
Pregunta 1: ¿Podemos completar esta entrada
en un sprint?
Planning Poker proporciona la respuesta a esto.
Ayuda a los equipos Scrum a comprender los elementos de la
cartera de productos y obtener una comprensión común de su alcance. El modelo
para esto es una ronda de póquer.
Estas son las reglas:
- Cada
desarrollador recibe tarjetas idénticas, que normalmente contienen números
de la serie de Fibonacci.
- El
equipo selecciona una entrada de sprints anteriores que se completó dentro
de un sprint, involucró a tantos desarrolladores como sea posible y es
representativa del trabajo del equipo. A esta entrada se le asigna un
tamaño (por ejemplo, 21).
- El
Product Owner presenta el elemento a estimar del Product Backlog.
- Los
desarrolladores estiman la entrada asignándole un tamaño basado en la
entrada de referencia. Si cree que la entrada es más grande, elija un
número mayor que 21. Si cree que la entrada es más pequeña o del mismo
tamaño, elija un número menor o 21.
Los desarrolladores continúan planificando el póquer hasta que
se alcanza un entendimiento común del elemento de la cartera de productos.
Planificar el póquer puede ser complicado y tiene muchos
peligros ocultos. Para no tropezar, recomiendo mi artículo “ La psicología oculta detrás de Planning Poker:
¡Cómo evitar 3 errores típicos y aumentar la precisión de tus estimaciones!” “.
Al preguntar el tamaño de un elemento del Product Backlog antes
de la planificación del Sprint, ayuda a su equipo a comprender si el trabajo
puede ser demasiado grande para un Sprint. Si este es el caso, puedes
dividirlos antes de Sprint Planning y ahorrar tiempo en Sprint Planning.
Ahora a la siguiente pregunta:
Pregunta 2: ¿Cómo podemos dividir esta
entrada para terminar antes?
Una forma de responder a esta pregunta es el método de la
hamburguesa.
Fue desarrollado por Gojko Adzic .
Me gustaría presentar aquí una variante que también explico a los participantes
en la formación “ Habilidades profesionales de gestión del backlog
de productos Scrum ”. En
el entrenamiento no nos limitamos sólo a la imaginación, sino que también la
aplicamos juntos. De esta manera podemos aclarar todos los problemas y
preguntas que obstaculizan la implementación en el equipo.
Estos son los pasos de un vistazo:
- Identificación
de pasos: Primero,
dividimos la funcionalidad en pasos de alto nivel para comprender qué se
debe hacer para este elemento de la cartera de productos. Estos pasos
crean las capas de la hamburguesa entre los panecillos.
- Identificación
de otras opciones: el equipo desarrolla varias opciones sobre cómo se pueden
implementar técnicamente los pasos individuales. Después de este paso,
tenemos varias opciones de solución técnica para cada paso.
- Combinando
todas las opciones: Ahora combinamos todas las opciones alternativas y creamos la
hamburguesa.
- Recorte
de la hamburguesa: Decidimos el nivel mínimo de calidad requerido por paso. Para
ello, comprobamos las alternativas y anotamos en las opciones lo compleja
que sería la implementación. También podemos seleccionar opciones que
requieran aproximadamente el mismo esfuerzo y sean intercambiables.
- Dar el
primer bocado: Finalmente,
decidimos cómo debería verse la primera versión de la entrada del backlog
del producto: ese es el primer bocado. Al marcar las alternativas en la
hamburguesa, también obtenemos una descripción general de posibles
actualizaciones futuras de la función.
Haga esta pregunta a su equipo sobre cada elemento de la cartera de
productos y utilice el método de la hamburguesa para dividir los elementos. Si
esto sucede antes de la Planificación del Sprint, evitará discusiones
interminables sobre alternativas de implementación durante la Planificación del
Sprint.
Ahora a la última pregunta:
Pregunta 3: ¿Cómo podemos recopilar
comentarios de los usuarios antes?
El objetivo de Scrum es terminar antes para recibir retroalimentación
más rápido.
Un requisito básico para ello son las entradas pequeñas. Cuanto más
pequeña sea una entrada, mejor, porque las entradas pequeñas se pueden
completar y entregar al cliente en un sprint. Sólo cuando los usuarios
realmente utilizan la función descubrimos si realmente agrega valor.
Sin embargo, el envío siempre implica costes considerables. El trabajo
debe planificarse en la planificación de sprint, diseñarse la interfaz de
usuario, programarse la función, probarse la funcionalidad y crearse la
documentación. No importa cuán pequeño sea el elemento de la cartera de
productos que se reduzca, estos costos nunca llegan a cero. Y si la función no
es útil, desarrollarla se considera un desperdicio.
El 99% de las veces cuando una característica no es útil es porque
basamos el desarrollo en suposiciones que no se concretan más adelante.
Asumimos
- que
este diseño llama la atención de los usuarios sobre la función,
- que
esta funcionalidad resuelve un problema para nuestros usuarios y
- que la
documentación ayude a los usuarios a comprender la función.
Sin embargo, estas suposiciones a menudo se pueden verificar de manera
mucho más rentable que si la función se desarrollara completamente y se
entregara a los usuarios.
La invitación a explorar posibilidades para esto es:
"¿Cómo podemos recibir comentarios de los usuarios antes?"
Esta pregunta nos invita a cuestionar los supuestos que hacemos en el
desarrollo y a buscar formas de probarlos desde el principio.
A continuación, se muestran algunas formas en las que puede ayudar a su
equipo a probar suposiciones:
- Entrevistas
con usuarios: a
través de conversaciones directas con los usuarios, el equipo Scrum
intenta comprender sus necesidades, experiencias y actitudes haciendo
preguntas específicas y analizando las respuestas.
- Observaciones
de usuarios: Las
observaciones de usuarios implican observar a los usuarios realizando
tareas específicas. Esto ayuda a identificar problemas de usabilidad y
sugerir mejoras.
- Encuestas: método de
investigación cuantitativa que recopila datos mediante la distribución de
cuestionarios a un gran grupo de usuarios para capturar opiniones,
preferencias y comportamientos con respecto a un producto o servicio.
Puede obtener más información sobre cómo verificar las suposiciones al
principio de mi artículo “ ¿No
hay diseñador de UX en el equipo? Con estas 3 técnicas simples, su equipo Scrum
puede comenzar a realizar investigaciones de UX hoy ".
Verificar las suposiciones también tiene un impacto positivo en la
planificación del sprint. Cuantas más suposiciones verifique el equipo Scrum en
el refinamiento, mejor comprenderán los desarrolladores a los usuarios, sus
problemas, necesidades y posibles soluciones. Este entendimiento compartido
elimina la necesidad de discusiones sobre la planificación del Sprint sobre por
qué se debe desarrollar una característica.
Comentarios
Publicar un comentario