Mi pregunta original se planteó aquí: en Scrum, ¿cómo estimar las historias de investigación? y como sugirió @CodeGnome, creé una pregunta separada.
En mi opinión, los picos deben tener un límite de tiempo, ya que a menudo hay un atractivo para "5 minutos adicionales" que el programador cree que son suficientes para completar la investigación.
Entonces, mi preocupación es: ¿cómo se marcan los picos de tiempo usando los puntos de la historia? El concepto detrás de los puntos de la historia que conozco es que no deben estar relacionados con el tiempo, sino con una combinación de esfuerzo y complejidad de la tarea.
(nota al margen: creo que una vez que comience a usar la conversión de puntos de la historia a horas, será mejor que comience a usar horas. Le ahorrará algo de tiempo a su equipo haciendo los cálculos matemáticos en la reunión de planificación)
Entonces, ¿cómo debo manejarlo?
Los picos se estiman en puntos de historia. Las tareas relacionadas con el pico deben estimarse en unidades de tiempo. El cuadro de tiempo para un pico se calcula en función de las tareas asociadas definidas en el Sprint Backlog.
¿[C]ómo haces picos de timebox usando puntos de historia? [Son una] mezcla de esfuerzo y complejidad de la tarea.
Omitiste la "incertidumbre". Los puntos de la historia también son una medida de la incertidumbre. Una historia de usuario en la que nadie sabe por dónde empezar se acercará a una incertidumbre infinita, mientras que una historia bien escrita con buenos límites limitará la incertidumbre.
Por ejemplo, "investiga la cantidad de ángeles que pueden bailar en la cabeza de un alfiler" tendrá un alto nivel de incertidumbre, a menos que ya tengas un alfiler que se sabe que los ángeles usan como club nocturno. Por el contrario, algo como:
Como programador,
quiero explorar formas alternativas de representar la página de inicio
para que se cargue en menos de 1200 milisegundos.
tiene cierta incertidumbre acerca de la solución, pero también tiene objetivos bien articulados, límites claramente definidos de "suficientemente bueno" y es probable que sugiera enfoques para reducir la incertidumbre que al menos puedan dimensionarse para el esfuerzo.
A diferencia de una historia de usuario normal, no siempre se espera que un pico genere un incremento potencialmente entregable. Un pico es un éxito si agrega conocimiento al equipo y reduce la incertidumbre sobre una historia relacionada. Por ejemplo, el pico anterior podría resultar en el aprendizaje de que un equipo no puede reducir los tiempos de carga sin sacrificar el contenido o rediseñar la arquitectura. Eso es una victoria si ayuda al equipo a estimar otras historias de UI o UX. Incluso si el pico está incompleto al final del período de tiempo, reduce la incertidumbre sobre el nivel de esfuerzo requerido para alcanzar los objetivos relacionados.
Las historias se estiman en puntos de historia. Las tareas deben estimarse en unidades de tiempo, ya que son esencialmente una asignación del cuadro de tiempo adjunto. No hay reglas estrictas sobre esto, pero en mi práctica de Scrum:
Las historias en la cartera de productos se estiman en Story Points. Si bien hay excepciones, la mayoría de los picos pertenecen al Product Backlog, donde son visibles para el propietario del producto y la organización. La investigación tiene un costo asociado que debe ser asumido por el proyecto, y es responsabilidad del Product Owner priorizar la investigación a través del Product Backlog.
Las tareas del Sprint Backlog se estiman en unidades de tiempo. Parte de Sprint Planning es descomponer historias de usuario en tareas granulares en Sprint Backlog. Generalmente recomiendo dimensionar las tareas entre medio día y dos días; cualquier cosa más pequeña crea demasiada sobrecarga de proceso, y cualquier cosa más grande viola el principio subyacente de "hecho/no hecho".
Los picos, por definición, tienen un tamaño máximo de cuadro de tiempo de un sprint. Ese es tu límite superior. Al final de un sprint, el pico está hecho o no, como cualquier otra historia.
Los picos también tienen un mínimo implícito, que es el tamaño más pequeño de una tarea en el Sprint Backlog. Esto representa el costo mínimo de un pico para el proyecto, pero también se puede usar para crear un cuadro de tiempo dentro de un sprint para el pico.
Un pico tiene una estimación puntual de la historia. Cada una de las tareas exploratorias para un pico debe tener una estimación de tiempo en el Sprint Backlog. Usted maneja el deslizamiento de picos de la misma manera que maneja el deslizamiento de la historia de usuario: falle temprano. Si bien las tareas no requieren el mismo marco de tiempo rígido que el sprint en su conjunto, las tareas que superan sus estimaciones de Sprint Backlog se deben comunicar en el stand-up diario, y todo el equipo (incluido el propietario del producto) debe decidir qué hacer. hacer con los picos que no entregarán valor o que no se pueden completar dentro de su cuadro de tiempo.
Como ejemplo, una historia de dos puntos puede tener cinco tareas con un tiempo estimado de un día cada una. Por lo tanto, la historia tiene una caja de tiempo de cinco días, y cada tarea tiene una caja de tiempo de un día. Si una tarea excede su time-box de un día, se informa en el stand-up diario donde el equipo puede coordinarse y decidir qué hacer.
Quizás el equipo opte por destinar más recursos a la tarea, desplazando tiempo o personas de alguna otra historia que resultó más fácil de lo esperado. Por otra parte, tal vez el equipo decida que se ha recopilado suficiente información para cumplir con el objetivo de reducción de incertidumbre del pico. Por otro lado, el equipo también podría decidir que las ganancias potenciales del pico no valen la pena, poniendo otras historias en riesgo de no terminarse al final del sprint y, por lo tanto, eliminar el pico antes de tiempo.
Como puede ver, este es realmente el mismo árbol de decisiones que tiene el equipo con las historias regulares. La principal diferencia es que un pico generalmente está diseñado para alimentar las estimaciones de una historia relacionada en un sprint futuro, en lugar de entregar algo concreto. Como tal, incluso un pico "fallido" suele ser un éxito en el sentido de que reduce la incertidumbre o resalta la complejidad de una historia relacionada.
Como reflexión final, recuerde que los equipos Scrum exitosos se autoorganizan. Como maestro de Scrum, su trabajo es recordarle a la gente que respete las casillas de tiempo que asignan. Sin embargo, dentro de los límites del marco, es perfectamente aceptable que el equipo asigne o traslade recursos internos dentro de un Sprint.
En lenguaje sencillo, eso significa que el equipo es responsable de alcanzar el Sprint Goal. Si no logran los objetivos porque no respetan el time-boxing, esto se reflejará claramente en el gráfico de trabajo pendiente y en el Product Backlog, y debe abordarse en la Retrospectiva del Sprint.
El time-boxing es una herramienta; no es un fin en sí mismo. El marco requiere que se respeten los time-boxes para iteraciones y reuniones definidas. Sin embargo, dentro de un Sprint, el time-boxing pretende ser una herramienta para la toma de decisiones, no una línea en la arena que nadie puede cruzar.
Los malos equipos ignoran las cajas de tiempo. Los buenos equipos respetan las limitaciones impuestas por los time-boxes. Los grandes equipos saben cuándo pueden estirar un cuadro de tiempo autoimpuesto sin comprometer el Sprint Goal.
Si actualmente se encuentra en un escenario en el que, como sugiere CodeGnome, tiene Historias con puntos de historia y tareas estimadas en horas, elegiría su respuesta.
Willl también planteó un punto muy válido de que si está haciendo picos para las historias en el sprint actual, realmente debería simplemente incluir la investigación con la historia y dejar que los puntos de la historia para la historia reflejen la incertidumbre.
Si, como solían hacer mis equipos, tiene historias bastante pequeñas estimadas en puntos que luego no se desglosan en tareas de tiempo estimado, es un poco más complicado.
Mis equipos han probado dos enfoques:
Permita una cantidad máxima de tiempo por semana para picos
Solíamos permitir dos días de picos por sprint de dos semanas.
Time-box y puntos de uso
También intentamos tener un valor de puntos estándar que adjuntamos a los picos con un período de tiempo determinado (por ejemplo, un pico de medio día podría ser 1 punto, un pico de dos días 5 puntos).
En estos días, no estimamos las historias en absoluto, entonces puede tratar todo como '1', independientemente de si se trata de un pico o una historia, ¡y ese problema en particular desaparece!
En mi experiencia, la respuesta es no .
Hemos hecho dos tipos de picos hasta ahora:
Pero la conclusión es que nunca hemos visto ningún valor en la estimación de picos en los puntos de la historia. La naturaleza del trabajo es completamente diferente, por lo que los puntos de la historia no están calibrados para ello.
He estado luchando con picos desde que soy ScrumMaster. Finalmente estoy empezando a aceptarlos, y así es como:
Dentro de mi organización, hay un debate en curso sobre la utilidad de los picos. Una vez que acepté que el equipo es responsable de sus propias decisiones, me retiré del debate.
Dado que el aumento o la investigación son necesarios para permitir la finalización de una historia de usuario, solo debe estimarse de la misma manera que lo haría con cualquier otra subtarea. Si normalmente divide las historias de los usuarios en tareas que se miden en horas ideales, entonces el pico simplemente se convierte en una de estas tareas, por ejemplo.
Esto no afectará tu velocidad ya que se requiere trabajo para completar la historia. Tu velocidad muestra cuántos puntos de la historia puedes completar en una iteración. Si completar las tareas de investigación es necesario para completar cada historia de usuario y no lo estimas como parte de la historia, entonces vas a dañar tu velocidad de todos modos. Este daño probablemente será más adverso de lo que podría pensar porque perderá los puntos de toda la historia si no se completa porque no tuvo en cuenta el trabajo de investigación. Si, en cambio, lo hubiera estimado correctamente, podría haberse dado cuenta de que no encajaría en la iteración y podría haber elegido una historia más pequeña que le daría una ganancia de velocidad neta.
Puede encontrar que el resultado del pico significa que tiene que volver a estimar otras tareas o historias, pero eso no es realmente un gran problema. No importa en qué esté trabajando, esto podría suceder: la interfaz de usuario se vuelve más difícil de codificar de lo esperado, un sistema heredado extraño hace que todo lo demás se rompa, etc. El punto es que si no lo incluye como una tarea, está configurando usted mismo para una caída.
ben