¿Cómo trabajar tareas inestimables en un scrum sprint? [cerrado

Question

Soy el maestro de scrum para un pequeño equipo de 4 desarrolladores. El proyecto en el que estamos trabajando tiene muchas tareas que nunca antes hemos realizado y no podemos estimar fácilmente en una reunión de planificación de sprint. ¿Cuál es la mejor manera de ejecutar un sprint con esta incertidumbre? Me resulta muy difícil terminar un sprint con un producto potencialmente liberable. También me resulta difícil planificar sprints cuando hay muchas tareas de longitud desconocidas.

Answer 1

No estoy seguro de cuál es el término en scrum, pero en la terminología de la historia del usuario haría un "pico", que es básicamente un período muy corto de investigación sobre el tema para que su equipo pueda estimar la tarea en el Fin de la espiga.

Ejemplo:

Historia:

El analista quiere poder revisar los datos financieros en gráficos circulares.

Su equipo no usa ninguna herramienta de gráfico, por lo que debe saber cuánto tiempo tomaría construir algo como esto. O tal vez en cambio, podría invertir en herramientas de terceros e integrar un conjunto de herramientas con su aplicación.

Haría un pico para investigar estos lugares y encontrar estimaciones sobre ellos, luego decidir qué ruta tomar.

Answer 2

Son las cosas de "tareas" que alguien en el mundo ha hecho antes, o son simplemente nuevas en su equipo. Asumiré lo más tarde. Si este es el caso, lo que está encontrando es que no tiene la experiencia necesaria en su equipo para resolver el problema. Por lo tanto, desarrollará esa experiencia a medida que avanza. Todo esto significa que la complejidad de sus historias es mayor. En los primeros sprints, puede obtener algunas de las historias como 13 y luego se convierten en 8s porque luego tiene el conocimiento que necesita.

No necesita saber cómo hacer las historias para estimarlas. Solo necesita asumir menos de ellos debido a su brecha de experiencia.

Me gusta reservar "picos" (sí, ese es el término utilizado en Scrum) para intentar resolver problemas de dominio comercial que no tienen una solución conocida. No es para que el equipo haga entrenamiento.

Answer 3

Si realmente necesita investigar para obtener una buena estimación, podría investigar como una tarea en sí misma, o dejarla de lado y hacerla (por alguien) antes de la planificación de sprint.

En general, creo que si no puede obtener una buena estimación, debe ir con una estimación incorrecta (es decir, una suposición salvaje) o debe bloquear el tiempo de la tarea, por lo que reserva una cantidad fija de tiempo para ello. una carrera. Después de eso, tendrá una solución hecha, o tendrá una mejor comprensión de ella para que pueda estimarla o dividirla en subtareas para el próximo sprint (o un sprint posterior).

Answer 4

¿Realmente te refieres a tareas o estás hablando de elementos de acumulación de productos (PBI)? En realidad, me resulta difícil creer que una tarea no sea estimable. Si realmente no lo son, es muy probable que sean demasiado grandes (las tareas no deberían exceder las 16 h, lo cual ya es enorme).

Si está hablando de PBIS, la situación que está describiendo es bastante sorprendente y en teoría no debería suceder. En el peor de los casos, solo asigne una gran cantidad de puntos de historia, esto significa precisamente que hay mucha incertidumbre en ellos. Pero, debido a que los PBI que están listos para un sprint no deberían exceder la mitad de su velocidad (o pondrá demasiado riesgo en su sprint), la forma obvia de resolver esta situación es dividir tales elementos en trozos más pequeños que pueden incluir exploración. Pero la parte importante es mantener las cosas con horario de tiempo, incluso (o especialmente) I + D. Tenga en cuenta que con Scrum, todo está en horario de tiempo.

En otras palabras, para reducir la incertidumbre, descomponga las cosas en cosas más pequeñas (¡sean ellos elementos o tareas)!

Answer 5

Si las tareas parecen imperdibles, creo que el mejor enfoque sería dividir esas tareas en tareas más pequeñas que puede estimar. Puede tomar varias iteraciones, pero probablemente se le ocurrirá un diseño de pseudo mientras lo hace. Joel menciona esto en uno de sus artículos.

Answer 6

Divida la tarea inestimable en una tarea para eliminar la incertidumbre y "el resto". Elimine la incertidumbre con pruebas de prueba de concepto o soluciones de pico. O programa el sprint y el resto del trabajo a continuación, o retrase el inicio del sprint durante una semana de picos.

Answer 7

A menudo no sabemos lo suficiente como para dividir una historia en las tareas. Tenemos un período de descubrimiento antes de saber cuáles serán las tareas. "Spikes" parece difícil de manejar. Por un lado, es posible que no pueda calcular el período del período de descubrimiento. En segundo lugar, no puedo planificar efectivamente un sprint sin saber cuánto tiempo llevará una historia.

Parece que otra opción es hacer el pico en Sprint 1 y las tareas en Sprint 2. La desventaja es que parece que el proceso obliga a una desglose antinatural del trabajo. ¿Por qué descubrir esta semana y luego esperar un rato antes de comenzar el trabajo?

Answer 8

Utilizamos "contingentes" o un atraso específico para tales tareas. los Herramienta scrum agilo apoya esta forma de trabajar y calcula esos problemas también, por ejemplo, en el quemado. De esta manera obtienes un buen control sobre los elementos "no planificables".

Answer 9

¿Eres confuso con precisión con la precisión?

La idea detrás de la estimación ágil es crear un número lo suficientemente bueno, no un número exacto. Es por eso que usar puntos de historia para la estimación de elementos de backlog es una mejor práctica; Hace hincapié en el esfuerzo/complejidad en lugar de la duración.

No necesita saber cuánto tiempo tomará cada tarea necesaria para implementar un elemento de retraso en un sprint. Lo que necesita saber es que, dado el trabajo al que se ha comprometido anteriormente en este sprint, ¿puede comprometerse con este artículo de cartera? Debido a que sabemos que no podemos saber exactamente cuánto tiempo llevará cada artículo de cartera, tenemos que hacer una suposición educada.

Más importante, ¿qué significa fallar en Scrum? ¿No se completan todos los elementos de Sprint Awardlog una falla? No ... si obtuviste cuatro de los cinco elementos hechos y el quinto se realiza principalmente, obtendrás crédito por los cuatro elementos completados (en términos de velocidad para el sprint), y cuando termines las tareas restantes para eso Quinto artículo en un sprint futuro obtendrá el crédito completo por ese artículo. Pero, ¿habrías hecho más si no estuvieras usando scrum? La única falla en Scrum es no aprender de sus errores, seguir haciendo las mismas cosas disfuncionales repetidamente mientras esperan resultados diferentes.

Entonces, en su reunión de planificación de sprint, no pases mucho tiempo preocupándote por algo que no podrás saber. Deje que el equipo piense en el trabajo y luego déjelos inscribirse en la cantidad de trabajo que se sienten cómodos que pueden completar durante el sprint. Si se subcomiteman, siempre puede arrastrar algo en la acumulación o terminar el sprint temprano. Si comprometen en exceso, entonces termina los elementos de la cartera de pedidos que puede en orden prioritario y discute por qué los elementos inacabados no se pueden terminar en la retrospectiva de sprint, junto con cómo evitar tener artículos inacabados en futuros sprints.

Por cierto, sé que esta fue probablemente una mala elección de palabras de tu parte, pero un Scrum Master efectivo no ejecuta el sprint. El equipo dirige el sprint, y el Scrum Master busca activamente impedimentos que disminuyan su productividad e interfieran con su capacidad para cumplir con sus compromisos. Scrum Masters no son gerentes, son una combinación de árbitros, entrenadores y anotador. Son los guardianes del proceso, ayudan al equipo a seguir el proceso, protegen al equipo de agentes externos que intentan dar la vuelta al proceso, y rastrean el progreso durante el sprint al garantizar que se actualice la acumulación de sprint y la tabla de quema de sprint se actualice Refleja la realidad, a diario. En la situación que ha descrito, donde el equipo no está seguro de cuánto trabajo debe inscribirse, el Scrum Master debería permitir que el equipo decida como un reflejo del respeto por la propiedad del equipo del compromiso. Cualquiera sea la decisión, no se equivocará.

Answer 10

Las picos deben estar en caja. Presenta la presión sobre el equipo para que limite el alcance y tenga una mejor idea sobre los costos-beneficios que implicará la investigación; es decir, es inútil llevar a cabo 3 días de investigación para una tarea que costaría algunos dólares.

Esto también está respaldado por el trabajo de Latham en la teoría de establecimiento de objetivos, donde aborda específicamente este problema.