¿Agile Inception o Sprint Cero? Entendemos que no hay “Sprint Cero” dentro de Scrum. Pero, ¿Cómo deberíamos llamar al proceso en el que creamos las historias iniciales en el Backlog para que el equipo pueda sacar esos ítems para trabajar en su primer sprint?
Si bien… esto es una pregunta cada vez más popular. Hay muchas propuestas y la respuesta más sencilla sería simplemente llamar a esta reunión “creación del backlog inicial” o “refinamiento” lo que quizás tendría mucho más sentido en el contexto de Scrum.
Pero lo realmente importante es saber que esto también dependerá de la organización, la cultura y madurez ágil, pero de aquí en adelante aprovecharé para llamarlo Agile Inception y contar algunas de las técnicas que utilizo para llevarlo a cabo.
¿En qué consiste un Agile Inception?
Empezamos cada proyecto con Inception, un ejercicio de descubrimiento que crea el escenario para un producto y produce un backlog inicial.
Personalmente me encantan los inceptions porque es una manera de poner sobre la mesa todos los elementos que componen un producto.
Claro hasta ese momento no hay software que funcione, pero se tiene una idea clara de por qué queremos construir algo.
Típicamente el proceso toma un día completo, y la asistencia incluye a todo el equipo (desarrolladores, gerentes de producto, diseñadores, analistas de soporte, UX, ingenieros, testers, etc.).
Un facilitador (agile coach / scrum master ) dirige la reunión para ayudar a establecer expectativas sobre cómo trabajamos y facilitar la transferencia de conocimiento entre los equipos.
Quiero añadir que hay muchos tipos de inceptions y que es probable que dependiendo de las características del proyecto/producto, se pueden mezclar los eventos y artefactos de cada uno.
Identificar las personas, roles y actividades
Esta sección podría ser fácilmente una serie de tarjetas, donde simplemente el grupo identifica todas las personas y roles que son importantes para entregar valor y alcanzar las metas.
Con esto en mente, se puede empezar a capturar los pasos en el flujo de trabajo de estos usuarios a medida que el producto entrega valor.
Por ejemplo una aplicación de calificación crediticia puede permitir que un usuario se registre, conecte sus tarjetas de crédito, confirme su identidad a través de su número de la seguridad social o dirección y vea su informe de calificación crediticia.
También podría permitir a un representante de ventas identificar a los miembros con bajas calificaciones crediticias y enviarles sugerencias sobre cómo mejorar su crédito (o venderles otra tarjeta de crédito).
Técnicas y recursos de apoyo
- Proto-Personas. Esta técnica propuesta por Jeff Gothelf muy útil para alinear al equipo.
- Value Proposition Canvas. Por lo general me gusta hacer este ejercicio una vez identificadas las personas para analizar cuales son las necesidades, trabajos y alegrías.
Recomiendo el libro de Strategyzer – Diseñando la propuesta de valor y Lean UX de Jeff Gothelf
Objetivos, riesgos y anti-objetivos
Identificar las metas suena obvio al principio, pero a menudo me encuentro con que existe un enorme desconocimiento de los objetivos y que cada miembro del equipo tiene una idea (o motivaciones) distinta.
En lugar de intentar priorizar al inicio, lo mejor es empezar por capturar todo lo que se ha podido identificar con los participantes de la sesión y luego agrupar los temas para los objetivos: políticas de la empresa, propuestas de valor, riesgos sensibles al tiempo, y posibles nuevas características.
Un buen contrapunto a las metas son los “anti-objetivos” o el “no-haremos”, un término para capturar todo lo que podría ser importante algún día, pero que representa una amenaza para lograr las metas.
Es importante asegurarse de que cada elemento en los anti-objetivos pertenece allí, y todo el mundo está de acuerdo (y sabe por qué).
Esto por sí solo ahorrará enormes dolores de cabeza a la hora de implementar las características – si, por ejemplo, el diseño optimizado para móviles no es una meta para el MVP, los desarrolladores pueden pasar menos tiempo construyendo y probando esa área de la aplicación.
Más importante aún, saben que tienen más autonomía porque entienden por qué no deben enfocarse en la optimización móvil y tienen el contexto para re-evaluar más tarde si todavía es un anti-objetivo.
Estos son capturados entregando tarjetas a cada miembro del equipo, donde anotan los riesgos (¡uno por tarjeta!). Algunos riesgos importantes a tener en cuenta son:
- Riesgos de negocio (¿El mercado quiere esto? ¿Una tecnología emergente interrumpirá este producto?
- Riesgos técnicos (¿Existen integraciones de terceros? ¿Existen tecnologías o librerías desconocidas para aprender? ¿El producto se basa en plataformas que están cambiando, por ejemplo, iOS, Android?
- Riesgos de programación (¿Existen puertas de acceso a la fase previa al MVP para satisfacer a terceros, por ejemplo, desarrolladores en otro equipo? ¿Existe un hito inamovible a corto plazo como el lanzamiento de un evento?
Cuando todos terminan de escribir, se recogen todas las tarjetas y el facilitador empieza a encontrar temas aquí. Los riesgos son cruciales para entender las prioridades y representan áreas que necesitan mitigación activa. Presta atención a tus riesgos durante todo el proyecto y asegúrate de que puedes marcarlos mientras construyes.
Técnicas de Apoyo
En esta parte recomiendo completar el Value Map de Strategyzer. En este vídeo se puede apreciar como encontrar el Product Market Fit, entre nuestro segmento de clientes y lo que podemos ofrecerle a través de nuestra propuesta de valor.
Story Mapping
Ahora que tenemos los flujos de alto nivel, empezamos a recopilar el elemento más importante de un proceso ágil: las historias de los usuario.
Con el tiempo he descubierto que las tarjetas de codificación por colores sirven como guía visual para la creación de las historias.
Escoja un color (azul) y escriba “Como <USUARIO>” – este es el marcador de posición para todas las historias relevantes para los miembros.
Para cada actividad, el moderador dirige la conversación sobre las historias que componen la actividad.
En sucesión rápida, crear cartas del mismo color para la historia y colocadas verticalmente bajo la “Persona”.
Estimación a Alto Nivel
Ahora que tenemos nuestras historias, es hora de darles una estimación.
Aunque no es común para la industria en su conjunto, dependemos de los desarrolladores para proporcionar estimaciones sobre la complejidad de la historia.
Los desarrolladores discuten historias y deciden cuantos de puntos de usuario asignarles basados en el esfuerzo.
Todo el equipo de producto debe estar disponible para aclarar las preguntas. Una vez que todos se sientan seguros de que la historia han sido estimadas razonablemente, escriba el total de puntos en la parte inferior derecha.
Ahora se tiene un conteo de puntos para el proyecto, y se puede discutir la línea de tiempo del proyecto dada una velocidad estimada.
Priorización
Una vez que las historias son estimadas, se puede empezar a formar un backlog colocándolas en orden de prioridad.
A menudo esperamos el Product Owner o el Product Manager dirija esta actividad, pero a menudo se establece un esqueleto que tenga sentido en un contexto de desarrollo ágil.
Es importante volver a repasar de nuevo a los objetivos y riesgos a medida que se priorizan las historias; ¿está dejando un montón de historias de importantes para el final? ¿Puede mitigar cualquier riesgo abordando las incógnitas antes? ¿Puede identificar mini-releases que aporten valor dentro del backlog?
Una bonita técnica de reforzamiento es marcar una una línea en algún lugar en medio de la backlog y preguntando que tan cómodos se sienten haciendo una release en ese punto.
Una vez que se sienta satisfecho con el backlog, revíselo con todo el equipo. Aproveche esta oportunidad para recapitular el día contando la historia de su proyecto a medida que se desarrolla y asegúrese de que ha abordado cada objetivo y los riesgos.
