2.0 KiB
| title | localeTitle |
|---|---|
| Spikes | Zapatillas con clavos |
Zapatillas con clavos
No todo en lo que trabaja tu equipo durante el Sprint son Historias de Usuario. A veces, una historia de usuario no se puede estimar efectivamente o se requiere investigación. Tal vez se necesita ayuda para decidir entre diferentes arquitecturas, para descartar algunos riesgos, o puede ser una Prueba de concepto (POC) para demostrar una capacidad.
En estos casos, se agrega un Spike al Sprint Backlog. Los Criterios de aceptación para el Spike deben ser una respuesta a la pregunta que se plantea. Si el experimento es más difícil de lo previsto, tal vez la respuesta sea negativa. (Es por eso que el Spike debería estar limitado en el tiempo).
El tiempo y la energía invertidos en el Spike se limitan intencionalmente para que el trabajo se pueda completar dentro del Sprint, mientras que otras Historias de usuarios tienen un impacto mínimo. El Spike generalmente no recibe un Estimado de Puntos de Historia, pero se le da una cantidad fija de horas para trabajar.
Demuestre los resultados de Spike en la Revisión de Sprint. Sobre la base de la nueva información, la pregunta original se replantea como una nueva historia de usuario en un Sprint futuro.
Su equipo obtuvo la información necesaria para tomar mejores decisiones; para reducir la incertidumbre. Con una cantidad pequeña y medida de sus recursos para aumentar la calidad y el valor del trabajo en futuros Sprints, en lugar de tomar decisiones basadas en el trabajo de conjetura.
Más información:
- Cabra de montaña Software Spikes
- Foro Scrum.org Cómo integrar un Spike
- Picos de Scrum Alliance y proporción esfuerzo-duelo
- Wikipedia Spike