El propietario del producto solicita una "comprobación de confianza" para alcanzar el MVP: ¿cómo hacerlo en un proyecto Scrum?

Si bien tal verificación de confianza no es nada sobre lo que haya leído en la Guía de Scrum , no lo veo como algo que viole Scrum de ninguna manera. De hecho, está respondiendo a una pregunta diferente: la de la confianza de las personas, no la de la fecha de finalización prevista.

El método nativo para responder una pregunta sobre la fecha de finalización esperada en Scrum se basaría en la velocidad y el tamaño del trabajo pendiente. Yo diría que simplemente contar el rendimiento (una cantidad de funciones completadas) es más simple y produce resultados similares . Independientemente del método que utilice, puede informar a las personas sobre su confianza. Por ejemplo: el rendimiento/velocidad medido hasta ahora sugiere que necesitamos 9 iteraciones más para terminar el backlog, pero estamos en el sprint 2 de 8, por lo que solo nos quedan 6 iteraciones; por lo tanto, mi confianza para llegar a tiempo es baja.

Otra parte que puede informar la confianza sería el avance del alcance: cuántas funciones se agregan a la acumulación de MVP a lo largo del tiempo. El hecho de que tenga, por ejemplo, 25 funciones en el backlog para el tiempo restante significa poco si puede esperar que cada iteración agregue 3-4 nuevas funciones al backlog. En tal caso, debe tener en cuenta que el tamaño real de la cartera de pedidos puede ser más como 43-49 funciones que las 25 actuales. Esto, también, informaría la confianza de las personas.

En cuanto a la validez del método, no lo veo como un gran problema siempre que haya un entendimiento común entre el PO y el CEO sobre lo que realmente significa la medición, y posiblemente todas las advertencias sobre la calidad de la medición.

Algunas observaciones que uno podría dibujar mirando la imagen:

• Mayoría de voces en la "esfera de incertidumbre" que es la mitad de la escala. Si no tengo opinión, o la tengo pero no estoy seguro, probablemente pondría mi voz en el medio. No importa lo que diga la etiqueta de "3" en realidad. Una mejora que veo para esta actividad sería agregar una opción explícita "No sé" para elegir. Eso resolvería las voces inciertas de aquellas que están "bastante seguras" de cumplir con la fecha límite.
• La gente es demasiado optimista en la estimación. Su experiencia no importa. El hecho de que hayan estado expuestos a sus propias estimaciones pasadas demasiado optimistas tampoco importa. Esto lleva a la conclusión de que, en realidad, las posibilidades de realizar el proyecto a tiempo son menores de lo que sugiere este ejercicio de confianza.
• Siempre que las personas que participaron en el ejercicio puedan estar seguras de que su resultado no se usará de ninguna manera en su contra, puede contar con datos confiables. La imagen sugiere que fue una votación anónima, lo cual es bueno. Sin embargo, todavía puedo imaginar al CEO tomando la acción después de que el MVP no cumpliera con su fecha límite. Después de todo, el equipo estaba "bastante seguro" de que lo lograrías. En cualquier caso, es importante que el equipo sepa que el objetivo puro del ejercicio es informar a los responsables de la toma de decisiones y que no hay ningún inconveniente para el equipo en participar en la actividad.

Los comentarios anteriores también sugieren cómo se podría haber mejorado la actividad: asegúrese al 100 % de que el equipo se sienta seguro con respecto a la medición recopilada, asegúrese de que el director ejecutivo comprenda las advertencias y que el equipo también lo sepa, dé espacio para "no tener idea" sobre confianza propia, asegurarse de que sea anónimo, etc.

André bienvenido al foro!

Te sugiero que:

• Reducir el número de "niveles". No necesita 5, lo hace menos procesable, 3 niveles probablemente sea mejor
• No preguntes por la probabilidad de que la respuesta de tu equipo dependa mucho de cuán optimistas sean. Creo que es mucho mejor construir preguntas cuantificables/objetivas que descubran la probabilidad del proyecto. Por ejemplo, el nivel de habilidades/requisitos específicos y hacer que las personas se evalúen a sí mismas sobre ellos, eso le daría una imagen mucho más clara que una simple pregunta sola. Para profundizar en esto, si, por ejemplo, necesita que todos se sientan cómodos usando la herramienta X que nadie sabe cómo usar, entonces dos buenas preguntas son: ¿qué tan cómodo se siente aprendiendo la herramienta X en esta cantidad de tiempo? y el segundo, ¿cuánto tiempo te llevó antes aprender una herramienta similar?

No creo que sea un gran problema pedir un voto de confianza. A menudo hago esto levantando las manos como un sí y un no o usamos los dedos en lugar de una escala como la que tienes tú.

Siempre y cuando el equipo no piense que un voto de confianza se toma como un compromiso o como un acuerdo firmado que entregará en una fecha fija.

La mayoría de las organizaciones establecen fechas fijas y esto suele ser una señal de que las personas que definen estas fechas fijas necesitan capacitación para comprender que en proyectos ágiles usamos zonas de aterrizaje, velocidad y alcance como nuestras palancas.

Una mejor manera de hacer esto es hacer que el equipo calcule el valor de 2 sprints listos para el trabajo de desarrollo y luego calcule el resto del trabajo pendiente a un nivel épico. Ingrese todos estos datos en un gráfico de quemado usando su velocidad promedio de los últimos 2 sprints y luego actualícelos constantemente a medida que sus cifras de velocidad lleguen en cada sprint (Jira hace esto automáticamente). Este gráfico de quemado le dará una zona de aterrizaje, es decir, un intervalo de fechas. Si está completamente apagado, entonces debe analizar detenidamente su MVP, eliminar las distracciones y otros trabajos del que el equipo aún podría ser responsable. Ser eliminado. En el peor de los casos, tendría que tener una discusión difícil con el director ejecutivo y el PO, instruyéndolos y mostrándoles estos gráficos.

llegando un poco tarde, pero lo he hecho varias veces, aunque no es específico de Scrum:

Obtener una evaluación honesta de la confianza de su equipo en cosas como esta (fechas de lanzamiento, requisitos completos) es realmente valioso, pero desafiante:

1. Honestidad: la autoinformación en el momento es difícil: desea que las personas respondan con algo de consideración, pero también sin la influencia de otros miembros del equipo. Y sin sentir que se están comprometiendo con algo.

   Idealmente, descubra una manera sin estrés de hacer esto de forma anónima . Quita la presión de tener "la razón", pero también le da a la gente tiempo para pensar en su elección.

2. Trayectoria: si solo se le pregunta una vez, puede parecer que su respuesta se tomará como un compromiso ("Estamos muy atrasados, pero Jane dijo hace tres meses que tenía mucha confianza en la fecha, ¿qué pasa? ").

   Lo ideal es realizar encuestas con regularidad y realizar un seguimiento de la tendencia a lo largo del tiempo. Ver la tendencia de la línea hacia abajo o hacia arriba es más valioso que cualquier número individual.

Hice esto manualmente en algunos proyectos, y ha sido muy útil para ver cosas como: La confianza en la fecha de lanzamiento era baja, así que investigamos un poco más, descubrimos que el equipo no estaba seguro de que hubiéramos capturado todos los requisitos, así que, aunque se estaban marcando todas las casillas, nadie estaba seguro de cómo todo saldría bien al final.

Tan útil, pero un poco complicado logísticamente (trabajo adicional para enviarlo, recopilar resultados, calcular cosas, etc.).

(Me duele tanto que en realidad acabo de escribir una aplicación ( ProjectPoll.co ) que hace esto por usted; si está interesado, siéntase libre de crear una cuenta y enviarme un ping, estaré encantado de configurarle un proyecto para intentalo.)

¡Este es un gran tema!

Estimar la confianza de forma regular (en retrospectivas) será útil para medir la salud del equipo y el crecimiento profesional a medida que todos trabajan en este nuevo territorio. El Scrum Master debe dirigir el proceso:

• El Scrum Master encuesta al equipo con un voto anónimo (1-5), inserta los datos en un histograma y discute los resultados como equipo inmediatamente.

• Discuta el "puntaje" de la semana individual y luego la tendencia.

• Idealmente, los números de confianza se mueven hacia la izquierda (los 4 y los 5 se hacen más grandes) a medida que se trabajan/revisan las historias de usuario y se adquiere conocimiento.

Tenga en cuenta:

• Los buenos resultados comienzan con Historias de Usuario bien definidas (no esperanzas).

• El desarrollo ágil produce producto y conocimiento (ambos son valiosos).

• El equipo de desarrollo y las partes interesadas deben hablar directamente directamente en las revisiones de Sprint.

Las necesidades de las partes interesadas pueden cambiar a medida que evoluciona la información/situaciones. Sea transparente y comuníquese sin miedo. Suerte y ve por ellos!!