¿Qué tan relajado (o no) debe ser un sprint?

¿Cuál debería ser la actitud hacia las historias que se asignan a un sprint? Obviamente, desea priorizar que se realicen en el sprint, pero para mí el punto más ágil es ser dinámico: no desea postergar deliberadamente o hacer que "esté bien" perderse las historias finales de los usuarios en un sprint, pero en Al mismo tiempo, cuando surgen cosas inesperadas, y esas historias no se completan y pasan al siguiente sprint, no quieres sentir que hiciste algo mal. Eso no debería ser una experiencia aterradora o negativa, ¿verdad?

¿Son aceptables las experiencias negativas / aterradoras para los compromisos de sprint perdidos? ¿Deberían hacerse responsables los desarrolladores de los compromisos de sprint perdidos cuando surgen tareas inesperadas que deben abordarse (por ejemplo, soporte de producción)?

Debes apuntar absolutamente a hacer los artículos dentro de un sprint.

Uno de los principales beneficios de SCRUM es que le da al proyecto un 'latido'.

Usted prioriza, selecciona elementos de una lista, los entrega, los muestra, refleja cómo fueron y luego lo vuelve a hacer en ciclos predecibles.

Toda la planificación, las estimaciones y la priorización se basan en este concepto. Que podemos y vamos a comprometer hacer X puntos dentro del sprint, y podemos, con el tiempo, establecer una velocidad a partir de la que podamos usar para una mejor planificación.

Si eres demasiado informal sobre el contenido y los compromisos de tus sprints, SCRUM simplemente se descompone en mi opinión y pierdes mucho sus beneficios.

Por supuesto, el mundo real a veces tendrá algo que decir sobre esto, pero esa debería ser la excepción y no la regla ...

La clave es que debe haber responsabilidad para no completar las historias.

Eso significa que debería haber una razón sólida por la cual una historia no estaba completa, y que esta razón se tiene en cuenta en el plan del proyecto en el futuro para que no se repita.

Esta razón debe ser más que un vago "surgió algo".

Por ejemplo, si una historia no estaba completa porque un miembro del equipo tuvo que trabajar en un problema de producción, entonces esta posibilidad debe abordarse en futuras iteraciones, ya sea planificando menos horas de este miembro del equipo o haciendo arreglos para otra cobertura.

Si la razón podría haberse evitado con más diligencia o trabajo duro por adelantado, entonces, sí, esta responsabilidad puede ser un poco dolorosa. Con suerte, el dolor es de la variedad "Esto es lo que necesitamos hacer mejor la próxima vez" en lugar de la variedad "No estás haciendo tu trabajo".

Eso no debería ser una experiencia aterradora o negativa, ¿verdad?

Si sucede una o dos veces, no, entonces no debería ser una experiencia negativa. Si sucede regularmente, tienes un problema. El equipo siempre está sobrecomprometido. Mejore en la estimación y piense dos veces sobre lo que se compromete en un sprint, pero no se ponga ansioso.

Los sprints relajados significan que tuvo un compromiso bajo.

Los sprints no relajados significan que tuvo un compromiso excesivo.

Solo entrego lo que me comprometo y trato de mejorar en el compromiso. Solo bajo circunstancias especiales movería una historia al próximo sprint. Prefiero tener una ligera presión todos los días que tener una gran presión poco antes de algunos plazos.

Basado en mi experiencia: como cualquier otra cosa ágil, nos adaptamos a un sistema de retroalimentación continua que incluye la estimación.

Está bien perder una fecha límite para el primer sprint (comienzo del proyecto) pero APRENDE de eso lo que salió mal (subestimación, no conocer las fortalezas del equipo, etc.). Luego tomas la retroalimentación y la alimentas al siguiente sprint y obtienes una mejor estimación.

Desde mi experiencia, han pasado 11 meses en mi nuevo proyecto ágil , rara vez perdemos la fecha límite ahora, si es que la perdemos. Pero perdimos la fecha límite para el primer sprint porque no sabíamos el ritmo y la fuerza de los miembros de nuestro equipo.

Algunas personas argumentan que "asignan" más tiempo para que el primer sprint supere el primer problema del sprint.

Es interesante ver las respuestas / comentarios aquí. En cada proyecto ágil (tipo) en el que he trabajado, la ventaja principal era distribuir la presión de la fecha límite en muchas fechas límite en lugar de una marcha de la fecha límite al final de un proyecto. En mi opinión, los sprints deben tomarse en serio. Cualquier falla en la fecha límite o la funcionalidad entregada deben verse como problemas potenciales en la gestión o el desarrollo del proyecto.

Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente. - Principios detrás del Manifiesto Ágil

Si es una experiencia aterradora o negativa, y sucede todo el tiempo, tienes un problema. El desarrollo de software debería ser divertido. No es negativo ni da miedo.

Sin embargo, si el equipo se compromete a terminar algunas historias en un sprint y continuamente no cumple, también tiene un problema. Es casi seguro que este problema no se resolverá agregando más presión al equipo para completar las historias. Si el problema se debe a factores externos, es necesario gestionarlos. Si el equipo se compromete demasiado, ScrumMaster puede guiar al equipo a comprometerse con menos puntos de historia. Puede haber muchas razones y cada una de ellas debe abordarse de manera diferente. Un equipo enérgico y motivado debe tener mucha motivación para avanzar.

Idealmente, sea cual sea el problema, se plantea durante la retrospectiva y se soluciona.

No debería ser tan complicado para el equipo descubrir lo que pueden lograr durante el período relativamente corto del sprint y luego lograrlo (una historia ocasional que pasa al siguiente sprint está bien, la velocidad puede fluctuar, las cosas cambian, etc. .). Si no puede hacer que eso funcione razonablemente sin problemas después de algunos sprints, está haciendo algo mal.

Realmente depende de tu línea de tiempo.

A veces, NECESITARÁS hacer todas las historias, o la mayoría de ellas de todos modos. Si bien Agile proporciona cierta flexibilidad, también necesitará terminar el proyecto, posiblemente en un plazo ajustado. Por lo tanto, tener la mayoría de las historias terminadas le permitirá terminar su proyecto a tiempo.

Dicho esto, sin embargo, surgirán cosas que te impedirán terminar cada historia, cada sprint.

Si el producto está en una línea de tiempo y se pierden historias clave, eso podría retrasar el producto. El producto retrasado en algunos casos puede dañar la posición competitiva de una empresa. Entonces, en ese caso, es posible que DESEA que sea una experiencia negativa que le falten historias, podría hacer que lo haga todo la próxima vez.

Cuando se dosifica correctamente, el estrés es bueno. Desea no quiere eliminar todo el estrés, solo desea distribuirlo de manera más uniforme en el tiempo. Incluso cuando juegues tu juego favorito, tendrás algo de estrés y sentimientos negativos. De hecho, obtienes más energía.

Un equipo debería sentirse realmente mal por las historias perdidas. Les dará energía para cambiar algo la próxima vez (trabajar de manera diferente o planificar menos historias, ambas son buenas). También deberían sentirse orgullosos cuando hacen sus historias, por supuesto.

También menciona tareas inesperadas (soporte de producción). Eso levanta una bandera roja conmigo. Debería haber un horario acordado para todos los problemas no relacionados con las historias. De lo contrario, el juego no es justo, el equipo se siente impotente y los sentimientos negativos no se utilizan para mejorar.

Debe observar los factores que hacen que sus compromisos fallen y tratar de solucionarlos. Grandes cantidades de eventos aleatorios seguirán arruinando tus sprints haciendo que tu velocidad sea impredecible. O arregla las causas de esto o introduce holgura en tus sprints. Prefiero arreglarlo.

De cualquier manera, el equipo no puede ser considerado responsable si su trabajo se ve afectado por factores externos. Use retrospectivas para investigar esto.