Inception vs sprint planning

He estado estudiando el marco de trabajo de Scrum y mientras más leo, más confundida estoy.
He estado revisando particularmente la etapa de Inception, que es la conceptualización del proyecto, pero de acuerdo a las técnicas que he revisado no sé si va dentro del sprint planning o es algo previo a iniciar SCRUM, si es así, como se une con el sprint planning? dónde realizo la estimación en puntos de historias?
Una de las técnicas en inception que he leído es:
hacer primero un Impact mapping y luego un User story mapping.
en esta última se habla de desglosar los entregables definidos, priorizarlos y armar los releases de cada sprint. Pero como puedo armar los releases si aún no tengo la estimación?

si alguien ha tenido esta experiencia y ha ocupado estas técnicas me puede aclarar??
gracias,

Hola Melissa ¿qué tal? Si lo que haz elegido para desarrollar tu producto de forma ágil es el framework Scrum, te comento que su implementación en propuesta no lleva una etapa previa de levantamiento. Scrum se basa en el desarrollo de producto por fases superpuestas o solapadas construyendo de modo iterativo incremental (una vez decidido cuál será el producto a construir).

Dicho lo anterior, se comienza desde el Sprint 1, donde tendrás tu primera planificación de Sprint (que puede durar el día completo en caso de ser necesario). En dicha planificación puedes utilizar diversas estrategias, algunas más adecuadas que otras de acuerdo al contexto. Por ejemplo, puedes utilizar tu primera planificación de Sprint para que el equipo de desarrollo estime todos los requerimientos del Product Backlog comenzando con las herramientas que tu mencionas. En lo personal, recomiendo más un Product Vision Board y en base a él, levantar un Go Product Road Map con los desarrolladores, así hacia la mitad del día, podrías volcar el foco en el Release 1 y seleccionar cosas para el primer Sprint considerando el valor que entregan para tus clientes las características seleccionadas, su riesgo, etc. El Product Backlog irá cambiando con el tiempo, puesto que el equipo de desarrollo y Product Owner irán aprendiendo más tanto del negocio como construir el producto y su trabajo colaborativo, por ende, las estimaciones de esfuerzo son relativas. Esto, por que entendiendo que las prioridades pueden cambiar, obligan a no diseñar un plan que te consuma gran esfuerzo. Lo anterior te obliga a planificar entregas mas pequeñas para disminuir el riesgo de fabricar cosas que se vuelvan obsoletas o que las prioridades cambien cuando estás al medio del desarrollo de algo.

Las estimaciones relativas sirven para medir el grado de conocimiento y convergencia de los desarrolladores acerca de tu Product Backlog, por consecuencia lo normal es que mientras mayor conocimiento, mayor convergencia, entonces, los requerimientos que estén al comienzo de tu lista, serán los que el equipo conoce mejor y generan menos dudas, lo que disminuye el riesgo, factor importante a considerar en los alcances de cada Sprint.

Scrum se basa en la teoría del control del proceso empírico. Dado que el empirismo sostiene que el conocimiento procede de la experiencia, este framework no piensa que tus estimaciones sean nunca realistas (pero si lo más cercanas a la realidad dentro de lo posible) ni aún utilizando los métodos más sofisticados, puesto que el futuro es algo que aún no ocurre y la realidad es demasiado compleja como para pretender capturarla en un plan. Sin embargo, existen técnicas para no estimar fechas, sino que pronosticar lanzamientos: “Si las condiciones para la fecha XX-XX-XX se mantienen, entonces podríamos lanzar”

Casi todos los proyectos tienen presupuesto y tiempo fijos. En Scrum, el alcance es variable, Ilustremos lo anterior con el siguiente ejemplo: Tienes un presupuesto que alcanza para sostener un equipo Scrum por 20 semanas. Han decidido iterar en Sprints de dos semanas así es que cuentas con 10 Sprints para fabricar el producto. El equipo de desarrollo tiene un Product Backlog con 75 requerimientos (o product backlog items, AKA PBI). Supongamos que al terminar el Sprint 1, el equipo logró construir 3 PBI. Lo razonable, sería planificar el siguiente Sprint con tres PBI más (y en caso de implementar mejoras en tu proceso para acelerar la entrega, se podría intentar sumando un PBI adicional). Lo que haces al finalizar el Sprint 1 es proyectar hacia adelante en el tiempo una entrega de tres PBI cada dos semanas, lo que alcanza para agregar 57 PBI más. Esto obliga a:

  1. Dejar cosas fuera del Product Backlog (preguntar siempre a los stakeholders ¿este PBI es realmente importante? ¿Se condice está necesidad con el mercado?)
  2. Si los stakeholders no quieren modificar el alcance, entonces deberán modificar el tiempo (nunca lo hacen hasta cuando ya es tarde y de forma reactiva)
  3. Si los stakeholders no quieren modificar el alcance y tampoco el tiempo, entonces negociar con ellos las mejoras que deben hacerse al proceso para poder construir más rápido el producto (les toca trabajar a ellos)

Cada vez que hagas un refinamiento del Product Backlog junto al equipo de desarrollo y también cada vez que se lance producto, el alcance irá variando hacia arriba o hacia abajo. En cualquier caso, repetir los pasos anteriores.

Puedes también utilizar la técnica de User Story Map en lugar del Go Product Roadmap, acá te comparto un muy buen artículo en español con tips bastante prácticos de como implementarlo desde el comienzo: User Story Map

Lo que NUNCA debes hacer, es castigar la calidad por cumplir tiempo y alcance.

Espero haber ayudado un poco en aclarar tus dudas, puedes encontrarme por Linkedin y con mucho gusto te ayudo en aclarar conceptos y compartir heridas de guerra.

https://www.linkedin.com/in/eduartegallardo

Saludos!!

1 me gusta

El Inception es una etapa previa de la ejecución con Scrum.

Para ser más específico, Todo producto nace de una idea/visión. Cuando ves Scrum, te habla de Product Backlog. Entonces ese viaje de convertir la visión a Backlog, la puedes trabajar con un Inception.

Es algo previo, las sprint están enfocadas a la ejecución del proyecto pero para llegar ahí tienes que tener la idea de proyecto, un backlog por donde comenzar, el mismo equipo de trabajo que participará de las sprints, etc.

Hola, veo que hay mucha confusion respecto de Scrum.
Inception o Sprint0 no son parte de Scrum, tampoco son realmente necesarias, ya que creemos en ideas emergentes mas que ideas perfectas. Ahora si a ud. le sirven para ordenar su trabajo y tiene tiempo para darse, adelante, mientras no le dedique tanto a planificar y mas a iterar usando empirismo.

Mientras tenga un item en el backlog, ya podemos comenzar y el trabajo emerge hacia donde esta el valor (si hace un buen empirismo)


Libre de virus. www.avast.com

1 me gusta

No existe un Sprint 0.

Aquí una referencia:

https://jeronimopalacios.com/2016/10/scrumclinic-sprint-0-e-inception/