Tips para el Sprint Backlog: Primero las HU Riesgosas y luego las prioritarias

Recordemos:

  • Sprint backlog: ítemes de backlog (en nuestro caso Historias de Usuario - HU) comprometidos a construir durante el sprint.
 


De las primeras cosas que aprendí en Scrum, al ver que un sprint fallaba fue:

Hacer de primero las HU más riesgosas y aunque no sean las prioritarias para el Product Owner (PO)


Razones:

  • si comienzas muy tarde a hacer la HU es probable que por sus dependencias o complejidad no la termines.
  • Obvio después de la(s) riesgosa(s) poner las HU que tengan más prioridad de forma que siempre estemos dando el máximo valor a medida que avanza el sprint.
 
Sugerencias:
  • Hacer ver al PO por que va esta(S) HU(s) de primero.- La verdad no es complejo-.
  • Debido a que esta historia va primero solicitar los insumos para hacerla, en caso que no estén,  poner una fecha máxima para la recepción de insumos, en caso contrario,  hacer ver que si no se reciben oportunamente la historia se cae (no se culmina), y esos puntos no se logran.
  • Lo ideal y recomendado es comenzar el sprint con los insumos (información, componentes, definiciones, etc) claros y resueltos para que el Sprint avance sin tropiezos.
  • Si una es HU riesgosa y se observa que la posibilidad de completarla es casi nula debido a su complejidad:
    • Definir un Spike (tarea dentro del sprint) con timebox definido (léase timebox=tiempo fijo) y objetivos definidos
    • Ese spike debe tener como objetivo eliminar la complejidad y adquirir el conocimiento necesario para lograr estimar y construir esa HU en el siguiente sprint
  • No tener muchas historias de usuarios riesgosas, a lo sumo 2 de un máximo de 7 HU (un sprint debería tener a lo sumo entre 6 y 8 HU), debido a que si son muchas el sprint puede ser un fiasco y no completar nada. (situación que viví y de la cual aprendimos como equipo)
  • Enfocarse y enfocar al equipo durante la ejecución del sprint en máximo 2 historias al tiempo de forma que se evacue siempre lo primero. Esto en Kanban se llamaría un limite de 2.

 Fuente: http://lecciones-aprendidas.blogspot.com/2013/09/tips-para-el-sprint-backlog-primero-las.html

La Magia de las Historias de Usuario / Desarrollo Conducido por Historias de Usuario

Cuando uno lee sobre RUP (Rational Unified Process), en una de sus definiciones dice que es un desarrollo conducido por Casos de Uso, y hoy quiero después de convivir por más de 6 meses con las Historias de Usuario, contar cómo realmente conducen el desarrollo del software mucho mejor que los casos de uso.


Introduciéndonos: El Formato

Las HU (Historias de Usuario) de usuario tienen un formato libre, y podrían expresarse como una necesidad funcional, por ejemplo:

  • consultar las películas de cine disponibles en un teatro cerca a mi casa
 
 O como ya es popular se pueden escribir con el siguiente formato (template):
 
  • yo como <rol> quiero/deseo/necesito  <funcionalidad> para <beneficio de negocio>
De esta forma nuestro ejemplo quedaría:
  • yo como cliente deseo saber cuales son las películas disponibles en un teatro cerca a mí casa para poder elegir que película ir a ver el día de hoy
Este formato tiene las consabidas ventajas de:
  • saber quien va a usar la funcionalidad y
  • comprender el beneficio del negocio de forma que el equipo pueda llegar a ese beneficio por distintos caminos
 

Y dónde esta la magia...

Aunque el objetivo de las historias es habilitar la comunicación entre el Cliente y Equipo (para el caso de Scrum:  Product Owner PO / Dueño del Producto y el Equipo de Desarrollo), dando cumplimiento al principios del manifiesto ágil:


Una definición tan simple obliga al equipo a estar en comunicación con el Product Owner (PO), de la siguiente manera:

  • En el Planning (ver más sobre scrum), el equipo pregunta al PO el detalle de lo que quiere y lo que espera.
  • En el Planning, el equipo con base en lo conversado estima lo que va a construir en presencia del PO.
  • Durante el Sprint, el equipo clarifica con el PO detalles menores olvidados.

Pero de todo esto lo que me tiene maravillado el día radica en los criterios de aceptación.

Los criterios de aceptación nos permiten reconocer cuando la historia esta HECHA / TERMINADA / REALIZADA (o criterio de DONE de Scrum), de esta forma el equipo de desarrollo no tiene pierde, pues todo su desarrollo esta orientado al resultado esperado, o mejor, orientado a los casos de prueba que a la especificación.

Esto es una ganancia enorme!!! (para quienes hemos padecido el desarrollo en cascada o RUP basado en casos de uso) la marcha de la muerte - o Desarrollo Orientado a la Frustración DOF - es la siguiente:


  • Analista: El casos de uso es especificado con sus  escenarios de uso (flujo básico, alternos y de excepción) -que a ratos solo los entiende el analista/desarrollador que los escribió -
  •  Desarrollador: Para cumplir con el caso de uso el desarrollador construye lo especificado en los escenarios de uso,  y valida contra unos escenarios de prueba que "el cree" necesarios para cumplir la funcionalidad.
  • Tester:  luego el tester mucho mas hábil en encontrar los errores (o enfocado en esa única tarea) construye n-mil casos de prueba a un solo escenario de uso (ejemplo flujo alterno 3 )  hasta que por fin le encontraba la caída al escenario del caso de uso y lo devolvía a desarrollo con un incidente o hallazgo (forma diplomática y "very polite" de decir bug), 
  • Desarrollador:  el desarrollador dice  "#$%#"% ese escenario YO NO lo considere, no estaba escrito en ninguna parte,  me demoraré un poco más en completar este caso de uso y entregarlo para pruebas"
  • Tester :  a lo que el tester responde "yo te entiendo, pero caso de prueba fallido es una forma de confirmar esa funcionalidad" 
  • Desarrollador : remata contestando el desarrollador  "tienes razón, nos vemos en X días cuando termine el desarrollo y marque como cerrada tu anotación en el Bugtracker"..

 y todos seguiremos tratando de dar lo mejor en un contexto que no lo permite, y que por lo general termina en una serie de enemistades:

  • Desarrolladores - Testers: - pues los desarrolladores comienzan a ver con malos ojos a los testers, por más claro que tengan el proceso de pruebas como una actividad de desarrollo.
  • Gerente de proyectos - Equipo: pues piensa "como es que se continúan atrasando en el cronograma, como es que no identificaron ese escenario, pensé que tenía un equipo profesional"
  • Cliente - Proveedor de desarrollo: pues el cliente piensa "como es que no son capaces de cumplir con lo especificado, casi que no completan esos casos de uso y miren todos los errores que tienen"



En cambio, en las historias de usuario ya sabemos como nos van a probar la historia y como se considerara TERMINADA.

Entonces para la historia de usuario que escribimos, los criterios de aceptación serán:

  • que me liste de a 10,20, ó 50 películas con su respectiva imagen y una corta descripción
  • que aparezca la calificación del público a la película
  • que aparezca la crítica a la película
  • que aparezca la distancia del cine a mi ubicación actual (tal vez esta pueda ser otra HU)
 
Aunque estos criterios de aceptación  son mejor expresados en el formato / template  BDD, de la siguiente manera:

En inglés, 
  • GIVEN 
  • WHEN
  • THEN 
o en español
 
  • DADO
  • CUANDO
  • ENTONCES
Este template permite la automatización de pruebas funcionales y obvio la mejor escritura de criterios de aceptación, veamos:
 
  • Escenario 1: listar de a 10 películas
  • DADO que me encuentro en cualquier sección de la aplicación
  • CUANDO selecciono ver listado de películas
  • -- antes no se ha seleccionado una cantidad de lista diferente 
  • ENTONCES el sistema me listará las 10 películas 
  • -- Y estás aparecerán en orden de estreno con su respectiva imagen y una descripción corta 
 
Y de esta misma forma se seguirían escribiendo los otros criterios / escenarios de aceptación...
 
 
Aun así ustedes me dirán, pero JORGEEEEE y 
 
¿la interfaz gráfica y la arquitectura?
R/ Pues tanto para la interfaz como para la arquitectura se definen unos lineamientos básicos para la aplicación antes de comenzar y estos irán evolucionando conforme pasa el tiempo. Si hay que definir algo de la interfaz gráfica se hará un boceto y se validará con el Product Owner durante el Sprint.
 
 

¿ y si queda faltando algo?
R/ Fácil, estamos bajo el principio de transparencia,

  •  el equipo en el Planning preguntó y
  • el Product Owner contestó, y 
  • con base en esto se estimaron unos PUNTOS DE HISTORIA (USER STORY POINTS ), 
  • se realizó el tasking de lo que se iba a construir (identificación de las tareas para construir las historias de usuario), y
  • se estableció el compromiso de las historias a construir en el Sprint.

Por lo tanto, si quedó faltando algún escenario por contemplar,  SIMPLE:

 "ENTRA COMO UNA HISTORIA DE USUARIO NUEVA PARA EL PRODUCT BACKLOG"
(no les parece esto una maravilla, a mí sí)


Esta historia debe ser priorizada, además sino se identificó y es muy importante, podemos contestar: "tranquilo Product Owner en el próximo Sprint lo incluimos que máximo lo comenzamos en 2 semanas".


Y dónde quedan los bugs / incidencias / hallazgos o como le queramos decir...

Wow, este tema con la pregunta anterior era uno de los objetivos a los que tenia con este post, la respuesta es otro abracadaba, "DESAPARECEN o TIENDEN A CERO" (nada por aquí, nada por acá como diría Harry Houdini).

La razón es muy simple, si desarrollamos orientados a casos de prueba una historia de usuario no estará finalizada hasta que cumpla todos sus escenarios y cumpla todos los criterios de DONE,estos son;

  • cumplir los aspectos funcionales, 
  • cumplir con los criterios de aceptación y de pruebas (ya sean estas manuales o automatizadas).
  • encontrarse desplegado y funcionando en un ambiente determinado, llámese ambiente de pruebas, pre-producción, laboratorio, producción -en algunos casos , etc.



Por lo tanto, si una historia de usuario esta DONE significa que:

  • fue probada y certificada por el equipo
  • fue aceptada por el Producto Owner
Si llegase a existir un "BUG", con plena seguridad afirmo que fue un escenario no identificado, y por lo tanto una historia nueva debe implementarse.
 
 
De esta forma las historias de usuario REALMENTE SI CONDUCEN Y DELIMITAN EL DESARROLLO, y see convierten en un punto de encuentro y de sincronización de imagen mental (entre Product Owner y Equipo) de  lo que se desea construir (ni una linea de código adicional más - pues no es necesaria - , ni una menos - pues no cumpliríamos el criterio de DONE - )  y de lo que no se desea construir, pues respecto a esto último, no hay lío, pues nadie lo identificó, o no era necesario en el momento.
 
Adicionalmente, los costos por garantía  también desaparecen o tienden a cero pues no habrán sorpresas de escenarios no cubiertos en producción.
 

En Resumen

Las grandes ventajas que he visto son:

 

  • Estamos orientados al resultado y no a la especificación
  • No quedan escenarios sin probar, pues estos son explicitados en los criterios de aceptación, situación que si sucede con los casos de uso..
  • Lo que esta por fuera de los criterios de aceptación simplemente se convierte en una nueva historia de usuario y se le asignara prioridad
  • Cuando una historia de usuario esta DONE!! (CRITERIO DE HECHO, o REALIZADO) y con sus pruebas funcionales automatizadas, se puede dar por olvidada la historia de usuario, en el sentido que no nos tenemos que volver a preocupar de ella pues el desarrollo orientado a casos de prueba garantizará que no quedaron escenarios por cubrir. 
Puedo afirmar con tranquilidad
 

Características de una buena historia de usuario

Luego de hacer la CCC (Card, Confirmation, Conversation), definitivamente el criterio más importante que uso es cumplir INVEST:

  • Independiente: No requiere de otra
  • Negociable: Se puede reemplazar por otra de diferentes prioridad
  • Valor: Que sea necesaria y de valor para el proyecto
  • Estimable: Que el equipo se sienta tranquilo y seguro estimandola.
  • Small (pequeñas): que no sean grande, funcionalidades pequeñas
  • Testeable (verificable): que se le puedan realizar pruebas.
 
 
Yo añadiría, aclararía y uso los siguientes:
  • que su tamaño no supere los 3 a 4 días de una persona enfocada desarrollándola.(Asociado al criterio de Small). Obvio hay excepciones pero al máximo trato que durante un planning no se supere este criterio.
    • Razón: He observado que historias mas grandes quedan mal estimadas por mas buena intención que tenga el equipo de desarrollo, el equipo se siente seguro con este tamaño de historia. Determine cual es el rango para su equipo.
  • que su implementación toque todas las capas o que el resultado de su implementación tenga sentido para el Product Owner o al Cliente. Me explico, en caso de hacer desarrollos asociados exclusivamente a la Base de Datos o a temas complejos por ejemplo que no logran verse reflejados facilmente por el product owner, sugiero crear historias técnicas en las cuales se le explique al Product Owner el valor asociado a las mismas en el proyecto. (Asociado al criterio de Valor).
    • Razón: Evito al máximo historias técnicas pues son de difícil justificación - aunque no imposible, pues si son necesarias se hacen -, pero la razón principal es que este tipo de historias habilita el crecimiento orgánico.
  • que tenga a lo sumo entre 3 y 7 criterios de aceptación.(Asociado a los criterios de Small, Testeable y Estimable).
    • Razón: Más de 7 criterios, se puede  dividir la historia, menos de 3 se puede agrupar con otra.
  • que se pueda dividir cuando sea muy grande (Asociado a los criterios de Small, Testeable y Estimable).
    • Razón: La gran mayoría de las historias grandes se pueden dividir, esto permite más maniobrabilidad al equipo al momento de implementación.
  • preguntar lo más que se pueda sobre la necesidad de la historia de usuario  (Asociado al criterio de Valor). 
    • Razón: Después de varios sprints y coach que me han hecho, he aprendido a preguntar para ciertas historias que percibo innecesarias (validaciones de negocio excesivas, autocompletar recargados, etc):
      •  ¿ok es de valor, pero es necesaria?
      • ¿cuántas personas la usarán?
      • ¿cuántas veces la usarán en el año?
      • ¿es realmente útil? 
      • ¿prefieres al equipo trabajando en esa "validación xxxx "-por poner un ejemplo-  que en esta otra historia de usuario que agrega más valor al negocio?
      • ¿podemos postergar esto para el final y hacer otra cosa más urgente sobre la que tenemos clara la necesidad de implementación? (principio de LEAN - aplazar las decisiones, ver más aquí)
 
 
Respecto al Sprint
  • Busco siempre trabajar con  al menos hayan 6 historias de usuario por sprint. 
    • Razón: De esta forma el equipo tiene en que trabajar, con pocas historias de usuario se estarán obstaculizando entre sí.
  • Trabajo junto con el Product Owner para que existan al menos otras 6 historias adicionales 
    • Razón: Tener backlog para posibles reemplazos y/o negociaciones.
  • Trabajo junto con el Product Owner para que se tengan definidos al menos historias de usuario al detalle para los próximos 2 Sprints (completamente elaboradas, cumpliendo INVEST) y un 3er sprint con Historias de Usuario  sin mucho detalle.
    • Razón: Tener claro hacia donde va el producto.
  • La evolución del producto esta guiada por el Visual Story Mapping (ver más aquí)el cual tiene los objetivos de cada Release y las historias épicas que contendrá.
    • Razón: Tener claro hacia donde va el producto y saber cuan cerca estamos de hacer una liberación o release.

 

     Fuentehttp://lecciones-aprendidas.blogspot.com/2013/07/caracteristicas-de-una-buena-historia.html

Cómo luce (se ve) una historia de usuario - un pequeño ejemplo

Cuando se explican las historias de usuario, las personas no creen que son tan simples de escribir y creen que hay quedan cabos sueltos. La verdad es que si son simples (es solo cumplir el criterio INVEST [2] ) y no quedan cabos sueltos debido a dos elementos:

  • Criterios de Aceptación
  • Conversación

Las historias de usuario tienen dentro de sus objetivos:

  • sincronizar las espectativas del PO (Product Owner) con el Equipo respecto a una funcionalidad
  • servir como elemento que dirigirá construcción del software

A continuación quiero compartir un ejemplo de como luce (o se vé) una historia de usuario: 

Nota : todo lo referente al ejemplo de la historia de usuario, lo registraré en color azul.
 
TEMPLATE
Yo como  <usuario>
necesito / deseo / quiero  <funcionalidad>
para <beneficio de negocio>
 
USANDO EL TEMPLATE PARA UN SISTEMA DE PRESTAMOS CREDITICIOS
 
 SOLICITUD DE INFORMACIÓN LABORAL DEL CLIENTE
(Nota : El título no sobra, algunas veces también se le adiciona codificación a la historia)


Yo como  CLIENTE DEL BANCO
Deseo INGRESAR MI INFORMACIÓN LABORAL ACTUAL
Para QUE EL BANCO DETERMINE SI ME PUEDE PRESTAR O NO
 
 
Criterios de aceptación 
(se pueden manejar dos opciones)


Criterios de Aceptación
 en Prosa
Criterios de Aceptación
en Formato BDD
 
GIVEN – DADO
WHEN – CUANDO
THEN – ENTONCES
 
(La verdad, prefiero este formato, ayuda a que no queden cabos sueltos)
Que pida lo datos de la empresa
Escenario 1: Solicitar Datos de la empresa
 
DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO se soliciten los datos de la empresa
ENTONCES se pedirá el nombre de la empresa.
 
 
Que pida el nit (identificador único nacional para las empresas) y lo valide
Escenario 2: Solicitud de Nit
 
DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO solicite la información de nit
ENTONCES se verificará el número del nit que su estructura sea correcta.
 
Que pida salario actual
Escenario 3: Solicitud de Salario
 
DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando el salario
ENTONCES verifique que el valor sea entero y positivo
Y menor a $100.000.000
Que pida fecha de ingreso a la empresa
Escenario 4: Solicitud de fecha de ingreso
 
DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando la fecha de ingreso a la empresa
ENTONCES la fecha sea superior a 50 años antes a partir de hoy
Y la fecha sea inferior a hoy
Que pida tres comprobantes de pago
Escenario 5:  Solicitud de 3
 
DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando los comprobantes de pago
ENTONCES solicite tres comprobantes de pago en formato imagen.

---------
 
Conversación
 (la conversación son aclaraciones realizadas por el PO durante el refinamiento o el planning, y muchas de esas aclaraciones son solicitadas por los miembros del equipo al entender las historias de usuario y comprender el negocio)
  • Los datos de la empresa son nombre, teléfono y dirección
  • Que la validación del nit sea contra el web service de la Direccion de Impuestos (DIAN)
  • El minimo valor de salario actual debe ser el salario minimo, el que debe ser leído de la tabla de parámetros
  • La fecha de ingreso a la empresa debe ser superior a 6 meses
  • Los comprobantes de pago deben ser en formato jpg, gif y máximo de 2 megas cada uno.
(Como fruto de una conversación puede resultar que se actualicen los criterios de aceptación o solo que se deje el registro aclaratorio.