viernes, mayo 26, 2017

Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint


Hola a todos

Continuando con la reflexión acerca del tamaño de las historias de usuario y basado en la retroalimentación de mi estimado y bien ponderado amigo Lucho Salazar - @LuchoSalazarC, quiero compartirles esta tabla de tamaños sugeridos para las historias de usuario.

La siguiente tabla cuenta con las siguientes consideraciones:
  1. Es una sugerencia, cada equipo, cada producto tiene su contexto y tendrá sus propios números, prácticas emergentes y conclusiones.
  2. Esta basada en el artículo "Patterns for Splitting User Stories" de Agile for All (ver post) donde se sugiere que una buena historia de usuario debe tener entre 1/6 a 1/10 de la velocidad del equipo cada sprint
  3. Recordemos que el tiempo requerido para el DONE de una historia de usuario (del mundo del software) debe incluir todas las tareas técnicas que sean relevantes y requeridas, por ejemplo:
    • Análisis
    • Diseño
    • Implementación
    • Revisión Par (esta es una buena práctica)
    • Despliegue
    • Pruebas
    • Corrección
    • Despliegue
    • Pruebas
    • Actualización de documentación relevante para el equipo.
  4. Por ejemplo si consideramos un sprint de 2 semanas y un equipo de 5 personas, el tamaño promedio sugerido de Historia de Usuario está entre 5 y 8 días persona, por lo tanto, ejemplo si tomamos la de 5 días, le tomará tomará al equipo aproximadamente 5 días-persona, lograr el DONE (o sea, todas las activadades identificadas en el punto anterior)
  5. Debemos procurar que los ítemes del sprint backlog (las historias de usuario para el caso del software) sean de similar tamaño, no siempre se logrará, unas veces sí, otras veces no.
  6. Sigo considerando que el tamaño razonable de Sprint es de 2 semanas, máximo 3, pero siempre tender al tiempo más corto.
  7. Aunque muchas veces la construcción de historias de usuario de sistemas que tienen muchas capas requieren muchos muchos días de esfuerzo para lograr el DONE, si un esfuerzo requerido es superior a 10 días-persona, debe ser revisado cuidadosamente para determinar si es susceptible de ser reducido por técnicas de partición de historias de usuario.
  8. Si como Scrum Master estás pensando que tu equipo va solo a trabajar historias de usuario en el sprint, es falso, recuerda que asiste a todas las reuniones de Scrum (Planning, Review, Retrospectiva, Daily, Refinanmiento) y estas toman entre el 10% al 20% del tamaño del Sprint.




Hasta acá este pequeño compartir, espero les sea útil.

Saludos ágiles

Jorge Abad



jueves, mayo 25, 2017

Es en serio, las historias usuario tienen que ser pequeñas



Hola a todos
Quisiera compartirles hoy una situación que con seguridad les habrá pasado a algunos de ustedes.
Dentro de las primeras recomendaciones que como Agile Coach que se le comparten a un equipo de software que comienza a trabajar con Scrum es que “las historias de usuario tienen que ser pequeñas”, es decir:
  • Toman máximo 5 a 6 días-persona en lograr el DONE (o sea que todas las tareas de ingeniería sumadas toman ese tiempo: análisis + diseño + implementación + prueba par + corrección + despliegue + pruebas + corrección + volver a desplegar, entre otros)
  • Tienen aproximadamente 6 a 8 criterios de aceptación cada una (ver post)
  • El sprint backlog cuenta con entre 6 a 10 historias de usuario de similar tamaño (ver post), obvio no siempre se cumple esta condición pero debemos procurar de que sea así,
  • Que sea tan pequeña que quepa en una tarjeta (media hoja de cuaderno, ojalá menos)
Lamentablemente en ocasiones estas recomendaciones son tomadas a la ligera por el cliente o por los nuevos Scrum Masters, por los Product Owrners y por el equipo desarrollador, teniendo como consecuencia la aceptación de Historias de Usuario que más bien son Épicas, generando:
  • Sprint backlogs de 1 historia que sobre vive muchos sprints
  • Sprint backlogs de 2 a 3 historias y a duras penas lograron cerrar una
  • Entre otros casos

Algunos Pensamientos

Asociado a este antipatrón quisiera compartirles hoy varios pensamientos:
  • Si un sprint es de 10 días –por ejemplo - implica que si una historia de usuario toma 8 o más días-persona para lograr el DONE ocasionando que muy probablemente esa historia no se termine y deba ser completada el próximo sprint si el Product Owner la prioriza.
  • Si una historia toma más de dos o más sprints en lograr el DONE puede tener como causasNo hubo un correcto refinamiento del backlog y la historia no cumplido el requerimiento de ser pequeña (1)
    • Se aceptó una historia de usuario que no tenía sus dependencias resueltas y que otro equipo o alguien externo al equipo de desarrollo le juro y perjuro al Product Owner que las dependencias estarían resueltas durante el sprint, no cumpliendo así la Definition of Ready (verpost) – dependencias que pocas veces se resuelven 
    • La historia de usuario realmente es una historia épica (DURA DE MATAR) que sobrevive muchos sprints teniendo como causa la carencia de refinamiento y de partición de historias (ver recomendaciones para partición de historias)
    • Los criterios de aceptación están tan amplios que “le cabe un tren de lado” (así decimos en mi tierra – Colombia – ), de nuevo careciendo la historia de usuario de refinamiento y de la correcta partición (ver recomendaciones para particiónde historias)
    • Al momento de escribir historias de usuario estas no cumplen dos de los criterios de INVEST (1) – Estimables y Small –, pues realmente no son estimables, (algo que he observado es que las estimaciones se vuelven inexactas más allá de los 10 días-persona) agregando gran incertidumbre a la estimación hecha (ya sea por planning poker u otro método)

Consecuencias

Cuando estas recomendaciones no se siguen ocasionaran:
  • Muy probablemente no haya Review (o demo), pues no hay nada que mostrar, se le pregunta al equipo y dicen “hemos hecho mucho, nos hemos esforzado mucho y nada que terminamos”, por lo tanto no hay incremento, por ende no hay generación temprana de valor, lo que nos lleva a que Scrum “no funciona” porque no se cumplió lo que se prometió con el framework.
  • Si no hay demo, el Product Owner y Stakeholders sienten que el equipo no avanza
  • El equipo encuentra cada vez más y más tareas técnicas que no había identificado y parece esto no tener fin
  • Se genera deuda técnica funcional (pues muchas veces dicen entreguemos así y nos queda pendiente, esto, esto, esto y esto.. y ya veremos cuando lo hacemos)
  •  En la retrospectivas creen que el equipo está mintiendo, y se comienza a generar desconfianza en el ecosistema ágil que queremos crear.

 Es en serio,
las historias usuario tienen que ser pequeñas
las historias usuario tienen que ser pequeñas
las historias usuario tienen que ser pequeñas

Sino fallará tu implementación de Scrum.


Cerrando

Recuerda:
  • Seguir las 3 C´s (2) y el criterio INVEST(1) siempre, 
  • Realizar refinamiento de historias en la mitad del sprint de manera que lleguen en ready al planning (ver post de refinamiento)
  • Hacer una buena partición (slicing) de las historias de usuario (recuerda la guía)
  • Y Si tu Product Owner se aparece en el planning con una historia que toma más de 6 días-persona como Scrum Master o Team Member deberías (según el contexto)
    • no aceptarla, o
    • hacerle partición y negociación en el planning para lograr generar un entregable en el sprint
Hasta acá este compartir

Saludos ágiles
Jorge Abad

Notas, referencias, comentarios y aclaraciones

  1. INVEST
    • Independientes
    • Negociables
    • De Valor
    • que se puedan Estimar
    • pequeñaS (small)
    • que puedan ser Testeables
  2. Las 3 C’s
    • Card (caber en una tarjeta)
    • Conversación
    • Confirmación
  3. Te recomiendo estos dos excelentes post en esa misma línea:
    • Por Lucho Salazar - El Tamaño si importa (clic aquí)
    • Por Javier Garzas - ¿Por qué las Historias de Usuario deben ser lo más pequeñas posible? (ver post)

miércoles, mayo 03, 2017

Cómo Contratar, Encontrar o Formar un Scrum Master




Hola a todos

Sigamos con el post anterior: Las habilidades blandas -Soft Skills- de un Scrum Master 

Primero aclaremos algo que siempre es bueno resaltar:

"con dos días de entrenamiento nadie se hace MAESTRO de Scrum o Scrum MASTER"

Estos dos días y el posible examen de certificación que se presente, son el primer paso, y solo se acreditaría el conocer el framework, pero no implican una maestría y el dominio del mismo, esto es importante remarcarlo pues Scrum no es una metodología, es un framework (lo que implica que no es prescriptivo ni detallado) y como tal deja muchas cosas sin definir y según el contexto y la experiencia se adoptarán unas prácticas y otras no.

Volviendo al tema, como se contrataría o formaría un Scrum Master, vamos por partes:


¿Cómo contrataría a un Scrum Master?

Bueno, pues para contratar a alguien como Scrum Master tendría los siguientes pasos
  1. validaría el conocimiento del marco de Scrum
  2. validaría la experiencia, acá opino que es necesario al menos seis (6) meses de experiencia continuos de haber aplicado el framework para comprenderlo y saber adaptarlo
  3. le haría una entrevista similar a esta -http://www.lecciones-aprendidas.info/2016/05/entrevista-para-un-scrum-master.html -
  4. y cerraría con un Assesment Center (o centro de evaluación), que es un juego de roles donde las personas muestran su forma de priorizar, interactuar, decidir, etc., buscando identificar las habilidades blandas presentadas en el post anterior - http://www.lecciones-aprendidas.info/2017/03/softskills-scrum-master.html -
  5. (para los que tienen equipos avanzados) sugeriría que el candidat@ comparta con el equipo al que llega un día o dos, buscando que  facilite algunas reuniones  para determinar si tanto equipo como Scrum Master se sienten cómodos mutuamente.
Con estos elementos determinaría si se puede contratar o no al Scrum Master candidat@.


¿Cómo formaría un Scrum Master? (aplica en caso de que alguien dentro de la organización se postule a ejercer el rol por primera vez) (1)

En general comenzaría con dos premisas
Luego comenzaría el acompañamiento, que puede darse en dos modalidades
  • acompañamiento de un  Agile Coach
    • Para esto se puede usar el modelo Shu-Ha- Ri de artes marciales

    • Shu
      • El Agile Coach realizaría y mostraría como realizar al SM las siguientes ceremonias
        • Al menos dos planning (esto implica al menos dos sprints)
        • Al menos dos dailys (luego los otros dailys dejaría al SM los realice)
        • Al menos dos refinamientos  (esto implica al menos dos sprints)
        • Al menos dos reviews  (esto implica al menos dos sprints)
        • Al menos dos retrospectivas  (esto implica al menos dos sprints)
      • Luego el Coach acompañaría al alumno en dos sprints, invitando a que el facilite las ceremonias de modo que observen puntos de mejora y puntos a conservar.
      • Luego se le dejaría sol@ con su equipo y se le visitaría esporádicamente o por demanda
    • Ha y Ri 
      • Se requieren de constante comunicación  (muchas lecturas, mucho aprendizaje ) entre el Scrum Master y el Agile Coach para subir a estos niveles
  • Acompañamiento de otro SM con experiencia
    • en este sentido se darían los siguientes pasos:
      • El SM nuevo acompañaría al SM con experiencia al menos durante dos sprints de forma que vea como este realiza las sesiones con su equipo, resuelve los impedimentos, y se desenvuelve en el día a día.
      • Asignar al nuevo SM su nuevo equipo de trabajo
      • El SM nuevo acompañado por el experimentado realizaría durante los dos primeros sprints las ceremonias de Scrum, de forma que se se den recomendaciones sobre facilitación y mejores prácticas
      • Luego el SM experimentado asistiría por demanda o por iniciativa del SM nuevo al equipo buscando ver puntos de mejora
      • Cierre del proceso
Hasta acá este compartir.

Saludos ágiles

Jorge H. Abad L.


Notas, Aclaraciones, Comentarios y Referencias
  1. Un Scrum Master en formación le sugiero seguir las reglas hasta que las domine  y pueda obviar cosas, pero mientras esto llega le sugiero seguir las agendas de scrum  http://www.lecciones-aprendidas.info/search/label/agenda%20scrum