Las características representan partes del producto que aportan un valor significativo a sus usuarios. Las características suelen ser demasiado grandes para que se puedan trabajar directamente, por lo que se dividen en unidades de negocio más pequeñas: las historias. Con respecto a la planificación, se espera que la producción de una característica dure varios sprints. Las características ayudan a materializar la visión y compartirla con el equipo ágil y las partes interesadas (stakeholders).

En iceScrum, las características pueden tener un color único y cada historia asociada a una característica obtendrá el mismo color. Esta es una forma efectiva de discriminar historias visualmente, p. para conocer la característica que recibirá el mayor esfuerzo dentro de un sprint.

El flujo de trabajo de características tiene tres estados:

• En espera: no tiene ninguna historia con un estado más avanzado que Planeada,
• En progreso: no se ha cambiado a Terminada y tiene al menos una historia en un estado más avanzado que Planeada,
• Terminada: tiene todas sus historias Terminadas y ha sido pasada a Terminada (ya sea manual o automáticamente). No es posible crear historias sobre una característica Terminada.

Obtenga más información sobre los permisos de características en la documentación dedicada.

Se espera que una historia se realice dentro de una iteración, por lo que debe ser la más pequeña posible.

En iceScrum una historia puede ser de 3 tipos:

• Historia de usuario: una historia que aporta valor a los stakeholders/usuarios, como una nueva función o una mejora en el producto.
• Historia de defecto: algo que elimina valor y que debe ser corregido, generalmente lo que se llama un error.
• Historia técnica: una historia que aporta valor al equipo, p. para reducir el riesgo, aumentar el conocimiento técnico, mejorar la calidad técnica…

En iceScrum, una historia pasará por varios estados en su vida:

• Sugerida: Cada idea se envía primero al Area de ensayo.
• Aceptada: Si el Propietario del producto lo reconoce como una idea valiosa para el proyecto, se lo acepta en la Pila del producto.
• Estimada: Una vez que el equipo ha estimado el esfuerzo para terminar la historia, está lista para ser planeada.
• Planeada: La historia está planeada en una iteración que todavía no está en progreso.
• En progreso: La historia es parte de la iteración actual
• En revisión: El trabajo técnico está hecho y la historia se está probando / validando (solo con la aplicación de App Flujo de trabajo)
• Terminada: La historia ha sido validada por el Propietario del producto
• Congelada: La historia aporta valor pero no se ajusta a la visión actual (solo con la aplicación de App Flujo de trabajo)

A continuación se muestra una representación simplificada del flujo de trabajo de la historia. Incluye los estados de la historia, la ubicación de la historia para cada estado y los roles a los que se les permite realizar estas acciones. Algunas acciones permiten saltar varios estados, pero en aras de la simplicidad no se muestran en este diagrama.

Puede aprender más sobre los permisos de historias en la documentación dedicada.

Las pruebas de aceptación (a menudo llamados criterios de aceptación) se adjuntan a una historia para definir exactamente qué se espera de esta historia. Son el lugar donde se definen las reglas y restricciones comerciales relacionadas con esta historia. Deben escribirse para cada historia de usuario antes del comienzo del sprint. El equipo está consciente del resultado esperado tan pronto como comiencen a trabajar en esta historia.

Cuando el sprint está en progreso, puede cambiar el estado de una prueba de aceptación manualmente:

• Para verificar (default)
• Fallado
• Éxito

Hasta que una historia esté En progreso, todas sus pruebas de aceptación son Para verificar. Una vez que una historia es Terminada, todas sus pruebas de aceptación pasan a Éxito.

Puede aprender más sobre los permisos de pruebas de aceptación en la documentación dedicada.

Para producir una historia, el equipo necesita realizar actividades estructuradas como Tareas. A diferencia de los otros elementos presentados aquí, una tarea no es parte del resultado del proyecto, es más bien el medio para producir el resultado. Una tarea puede ser realizada por un solo miembro del equipo, mientras que producir una historia es responsabilidad de todo el equipo. Además de las tareas de historia, las tareas se pueden crear fuera de una historia como tareas urgentes y tareas recurrentes . Las tareas asociadas a una historia pueden evolucionar a medida que avanza la historia.

Cuando el sprint está en progreso, el estado de una tarea se puede cambiar manualmente arrastrando y soltando:

• En espera (por defecto)
• En progreso
• Terminada

Una vez que una historia es Terminada, todas sus tareas pasan a Terminada.

Puede aprender más sobre los permisos de tareas en la documentación dedicada.