• Principios de Lean Software Development, a modo de ayuda cuando Scrum no proporciona una solución directa a un problema.
• Cómo gestionar historias de usuario que comparten implementación, haciendo énfasis en no perder el foco de que toda historia de usuario debería proporcionar algún valor al cliente.
• Empezar por las historias de usuario más claras y que aportan más valor, y así en el futuro evitar modificar código de requisitos actuales dudosos.
• La “generalización” del producto puede ser peligrosa para el negocio, no hay que olvidarse de obtener resultados a corto-medio plazo para el negocio
• Cómo poner las pruebas de concepto en el product backlog, siempre sin perder de vista que el tiempo para estas pruebas debe estar acotado (timebox) y que debe poder medirse el progreso de la prueba.
• El backlog como iceberg, en el cual los primeros objetivos son más pequeños, están más detallados, y los últimos son meros recordatorios de grandes objetivos a conseguir.

 

• Respetar a las personas, por que el equipo es quien conoce cómo mejorar el proceso en que trabaja.
• Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor añadido en el producto.
• Aplazar el compromiso, retardar las decisiones hasta que se disponga de toda la información o no se pueda esperar más.
• Crear conocimiento, tener feedback regular con el cliente para alinearse con sus expectativas.
• Hacer entregas rápidas, para permitir que el cliente pueda aprovechar antes los beneficios que le aporta el proyecto.
• Desarrollar con calidad interna, de manera que el producto pueda ir creciendo con una velocidad sostenida.
• Optimizar la totalidad del proceso, mejorar el proceso de creación del producto, desde la idea hasta su entrega.

• Explicar al cliente esta situación. De esta manera puede tomar una mejor decisión de qué historia de usuario le interesa que se implemente antes (puede llegar el caso de que el cliente vaya retardando la segundo historia de usuario y que al final ésta no se implemente nunca).
• Ver qué orden de implementación de las dos historias de usuario es el que necesitará de un menor esfuerzo global.

• Se consiguen completar antes los requisitos que sí están claros (“Hacer entregas rápidas”).
• Cuando llegue el momento de incorporar los requisitos que en su día fueron dudosos (y puesto que la idea original puede haber cambiado), las modificaciones/refactorizaciones a realizar pueden ser menores que si se tuviesen que hacer sobre un código implementado a partir de requisitos no claros. En un caso extremo, puede ser que el cliente no necesite nunca esos requisitos.

• Si es posible, es mejor ser transparente con el cliente y que entienda el sentido y necesidad de realizar pruebas de concepto.
• Es más sencillo utilizar una única herramienta (el product backlog) para tener la visión de todos los objetivos en que está trabajando la fuerza productiva (el equipo).

• Hacer que el timebox sea pequeño (siempre menor que una iteración), pero suficiente para poder obtener un resultado y tomar una decisión. Si al final resulta insuficiente, se puede volver a utilizar otro timebox.
• Definir la estrategia de la prueba de concepto, dividiéndola en tareas que al completarlas permitan saber si se está progresando.
• Hacer varias pruebas de concepto para reducir riesgos. Por ejemplo, en el caso de una aplicación web, se pueden hacer públicas variantes de una misma funcionalidad (o diferentes funcionalidades) para diferentes usuarios, de manera que se obtenga feedack directo y real de su aceptación.

• En las primeras iteraciones, en que aparecen las historias de usuario más prioritarias, estas historias de usuario son más pequeñas y detalladas.
• Conforme las entregas son más lejanas, los objetivos se redactan como grandes temas que actúan a modo de recordatorio (“épicas”).

Artículos relacionados

• Planificación ágil vs planificación tradicional
• Introducción a la estimación y planificación ágil
• Videos cortos sobre planificación ágil
• Estimación y planificación ágil – Resultados del quinto encuentro ágil en Barcelona
• Replanificación del producto o proyecto
• Planificación ágil de proyectos dependientes
• Métricas ágiles y valor – VI encuentro ágil en Barcelona

• planificación_proyecto