¿Cómo proporcionamos estimaciones de tiempo válidas durante la planificación de Sprint sin hacer un diseño "demasiado"?

Mi equipo se está poniendo al día con Scrum, pero la mayoría de nosotros estamos más familiarizados con las metodologías no ágiles o "pseudo-" ágiles. La parte que es el mayor obstáculo para nosotros es llevar a cabo una reunión eficiente de Planificación de Sprint en la que dividimos nuestros elementos atrasados ​​en tareas y estimamos las horas. (Estoy usando la terminología de la plantilla VS2010 Scrum; disculpas si uso la palabra incorrecta en alguna parte).

Cuando intentamos calcular cuánto tiempo llevará una tarea, a menudo caemos en la trampa de diseñar la función a nivel de código (diseño de tabla, interfaces, etc.) para determinar cuánto tiempo llevará eso. .

Estoy bastante seguro de que este no es el lugar apropiado para hacer ese tipo de diseño. Deberíamos programar tareas para estas reuniones de diseño durante el sprint. Sin embargo, estamos teniendo problemas para encontrar la manera de obtener estimaciones significativas para las tareas.

¿Existen hábitos / técnicas prácticas / etc. por hacer una llamada de juicio sobre cuánto tiempo llevará una característica, sin saber cómo planea implementarla? Si nuestras estimaciones de tiempo van a cambiar significativamente una vez que se haya completado el diseño, ¿cómo podemos presupuestar adecuadamente nuestra reserva de Sprint con anticipación?

EDITAR:

Solo para aclarar, ya que algunos de los comentarios / respuestas son muy válidos, pero creo que abordar la pregunta incorrecta.

Nosotros sabemos que lo que estamos haciendo no está bien, y que deberíamos construir el tiempo en el sprint para este diseño. Conceptualmente, todos los desarrolladores entienden eso. También traemos a un miembro del equipo con experiencia Scrum para mantenernos en el camino si comenzamos a adentrarnos en la maleza.

El problema es que, sin pasar por este proceso de diseño, nos resulta difícil proporcionar estimaciones de tiempo concretas para cualquier cosa. Constantemente decimos cosas como "bueno, si lo diseñamos de esta manera, podría tomar 8 horas, pero si terminamos teniendo que hacerlo de otra manera, eso tomará alrededor de 32, pero podría no ser tan malo una vez que comencemos a escribirlo ... ".

También supongo que este proceso mejorará una vez que tengamos cierta velocidad histórica para trabajar, pero muchas de las tecnologías y patrones arquitectónicos que estamos utilizando son nuevos para nosotros. Pero si las estimaciones potencialmente erróneas son solo una parte natural de la adaptación de este proceso, entonces solo tendremos que reacondicionarnos para aceptar eso :)

1. Programe una reunión periódica de "preparación" donde tenga estas discusiones de diseño. El equipo en el que estoy los tiene una vez por sprint, el día antes de la planificación. El objetivo allí es tener el diseño lo suficientemente definido como para que el equipo pueda acordar las estimaciones de tiempo para la historia general. Puede considerar desglosar las tareas en esta reunión, de modo que la planificación se convierta simplemente en un ejercicio para decidir cuánto recoger. En otras palabras, debe hacer el diseño en los sprints ANTES de comenzar a hacer el trabajo real.

2. Considere usar el póker de planificación , es decir, puntos / unidades de "esfuerzo" en lugar de días-hombre para estimar las tareas. Intenta también desglosar las historias tanto como puedas. Cuanto más larga / más compleja es una historia, menos probable es que su estimación sea precisa.

3. En la planificación, el scrum master debe mantener la planificación en marcha al detener cualquier discusión que llegue demasiado lejos a la "resolución". En ese punto, se requiere que los miembros del equipo lleguen rápidamente a un acuerdo sobre la estimación, generalmente dando un número de límite superior / peor caso. Es mucho más fácil retomar más trabajo si las tareas terminan siendo más fáciles de lo que planeas, que lidiar con el retraso de los cronogramas debido a que las tareas toman más tiempo de lo planeado y las historias pasan a varios sprints.

4. Hable acerca de cómo se obtuvieron las estimaciones en la retrospectiva al final del sprint. Particularmente si hubiera alguno que estuviera notablemente lejos. ¿Aprendió el equipo algo de cómo fue la historia versus cómo esperaban que fuera? El scrum master debe centrarse en los cambios accionables que se pueden realizar en su proceso de diseño / estimación.

Creo que el problema es que estás tratando de estimar el tiempo. No lo hagas

Estime la complejidad. Mire un requisito, (con suerte una historia de usuario) y califique qué tan complicado cree el equipo que será descubrir cómo construirlo y probarlo, en relación con lo complicados que son otros requisitos o historias de usuario. A veces te equivocarás, pero a menudo tendrás una buena idea de lo difícil que va a ser algo. También encontrará que los elementos que son casi de la misma complejidad tienden a requerir la misma cantidad de esfuerzo para completarse.

Por lo tanto, las clasificaciones de complejidad se convierten en los "puntos de historia" asociados con las historias de usuario en la cartera de productos. Después de trabajar algunos sprints, tendrás una idea de cuántos puntos de la historia puedes superar en un sprint, y esa es tu velocidad. En ese momento, tendrá una idea mucho mejor de cuánto tiempo llevará cada elemento.

Recomiendo encarecidamente las historias de usuario de Mike Cohn aplicadas .

Sé que su pregunta es específicamente sobre evitar el diseño en la planificación. Pero esto es una especie de problema XY .

He estado donde estás En lugar de darle algo que pueda proporcionar una mejora incremental, me gustaría ayudarlo a superar algunos de esos estados intermedios.

Aquí hay tres cosas que nuestro equipo hace específicamente relacionadas con la planificación y ejecución del trabajo. Estos nos han ayudado a evitar la agitación del diseño y escapar de estimaciones de tiempo inexactas.

Criterios de aceptación automatizables

Nuestras historias están señaladas por su número de Criterios de aceptación automatizables . Esto significa que si escribiéramos pruebas automatizadas para confirmar que la historia está hecha, ¿qué serían?

Por ejemplo, "Cuando el usuario hace clic en 'reproducir' en un iPad con iOS 6+, el video comienza a reproducirse". Puede ser difícil automatizar esta prueba, pero es un criterio de aceptación (AC) de la historia y aporta un punto.

Usamos la escala de Fibonacci, y siempre redondeamos. Entonces, si una historia tiene cuatro criterios de aceptación automatizables, es una historia de cinco puntos.

Nuestro tamaño máximo de puntos de historia es de ocho puntos, pero rara vez los tenemos. Si una historia tiene más de cinco criterios de aceptación automatizables, encontramos una manera de dividirlos.

Pre-aseo

Tenemos una reunión inicial el lunes, pero nuestras reuniones de preparación son donde ocurre la planificación del equipo. Antes de la preparación, los miembros del equipo prepararán una historia describiendo el resultado y apuñalando los criterios de aceptación automatizables.

Grooming aporta la experiencia del equipo a las historias preparadas, descubriendo requisitos no especificados, rompiendo historias, etc.

A veces enumeramos tareas además de los criterios de aceptación, pero estos no son estimados por tiempo. Nunca estimamos el tiempo. Las tareas son solo declaraciones de trabajo que deben hacerse en apoyo de los criterios.

Limitar el trabajo en progreso

El scrum tradicional intenta limitar el tiempo de trabajo a la duración del sprint. Descubrimos que esto artificialmente nos hizo apurarnos para cumplir con los plazos de sprint, matando nuestros fines de semana porque el sprint termina el viernes.

Otro enfoque es limitar el trabajo en progreso en un momento dado. Hemos migrado a este último y hemos sido significativamente más felices por ello.

Una vez que una historia pasa del trabajo atrasado al trabajo en progreso, la caracterizamos como uno de varios estados:

• En espera: el trabajo en equipo no puede suceder porque estamos esperando alguna actividad extra del equipo
• En desarrollo: trabajando para lograr los criterios de aceptación
• Prueba de necesidades: creemos que hemos cumplido con el AC, esperando que alguien más verifique
• En Test: la historia se está evaluando contra el AC, los errores se están abordando
• Listo para implementar: en la próxima oportunidad disponible, se pondrá en marcha

Luego usamos el número de historias en cada estado para impulsar el enfoque del equipo. Por ejemplo, un desarrollador puede estar disponible para asumir una nueva historia, pero si tenemos muchas historias en prueba, es mejor que ayuden en las historias existentes.

Primero, reconozca que las estimaciones precisas son imposibles bajo esas circunstancias. No te estreses si te equivocas. Sin embargo, aún necesita una idea aproximada para planificar, y realmente la única forma de explicar la incertidumbre completa es agregar más puntos de historia a su estimación. Si no sabe si es un 5 o un 13, use el 13.

También es útil desglosar las historias lo más pequeño posible. A menudo tenemos una historia de investigación / diseño con el único propósito de hacer el trabajo suficiente para tener una mejor idea de cómo hacer la función, luego la historia en sí misma entra en un sprint posterior. Piensa por qué esto funciona. Incluso si no tiene idea de lo difícil que será algo, generalmente sabe con bastante precisión por experiencia pasada cuánto tiempo llevará averiguarlo.

Hay dos cosas que puedes hacer aquí.

Primero tenga algún tipo de maestro scrum cuyo rol sea monitorear la discusión y decir "Hola, estás diseñando de nuevo" cuando lo estés. Es más difícil de lo que parece, rotar a las personas en él día a día e inicialmente hacer que todos sean el maestro scrum para que cualquiera pueda hablar.

En segundo lugar, si está diseñando durante la planificación del sprint, debe poder diferenciar entre no saber lo suficiente como para hacer una llamada sobre la duración de una tarea, o si solo está diseñando porque es más divertido.

Una vez más, el scrum master debería patear aquí y decirle que vuelva a poner el elemento en espera hasta que sepa lo suficiente para programarlo, o que deje de diseñar y responda la pregunta original (¿Cuánto tiempo tomará?).

Entonces, si está haciendo una planificación de sprint, tiene sentido tener un patrocinador de negocios allí para repasar el trabajo atrasado con usted y priorizar las cosas que quieren ver primero. Si haces eso, encontrarás que es más difícil diseñarlo durante la sesión porque se inquietarán y eventualmente no querrán venir.

Hemos estado operando sobre la base de estimar la historia 'fría' durante la planificación del sprint con solo una discusión limitada. Las estimaciones son realmente bastante inexactas a pesar de la creación de equipos con un enfoque razonablemente estrecho ... principalmente debido a la existencia de un código heredado indocumentado y no comentado sin una idea real de lo que realmente se supone que está sucediendo y un personal que ha cambiado en gran medida desde que se escribió el original.

Lo que estamos intentando ahora es pasar un poco de tiempo antes de planificar la investigación de cada historia, y aquí solo un desarrollador investigará una historia ... Esperamos que esto signifique que el desarrollador que investigó podrá proporcionar alguna aclaración y conocimiento para Ayudar a la estimación. Hasta ahora, esto ha ayudado en las ocasiones en que se ha probado.

Todavía tengo que estar convencido de que la investigación adicional realmente hace que las estimaciones sean lo suficientemente más precisas para justificar el costo, pero lo intentaremos durante unos pocos sprints para ver.