Hablamos de Slicing cuando cortamos un requerimiento en múltiples partes que siguen entregando valor de manera independiente (No sólo trabajes duro, trabaja inteligentemente).

Ejemplo: 

Comprometidos 2 requerimientos de 10 puntos cada uno para avanzar en un sprint: 1 requerimiento se completa y  otro se avanzaron 8 puntos, al no estar completo el segundo requerimiento no está generando valor y se estaría entregando en el sprint solo 10 puntos de 20. Usando slicing pudimos dividir de forma mas adecuada 2 requerimientos de 10 puntos y transformarlos en 10 requerimientos de 2 puntos cada uno y así a final de sprint entregar 18 puntos de valor de 20.

Método SPIDR

Criterios que se pueden considerar para hacer slicing con facilidad una vez que estás trabajando con historias de usuario para gestionar mejor el trabajo. SPIDR es el acrónimo de SPIKE, PATH, INTERFACES, DATA y RULES.

SPIKE

Los Spikes son un término utilizado para definir pruebas de concepto: elaboración de prototipos, validación de supuestos, factibilidad técnica o incluso reducción de incertidumbre. Es decir, generar una nueva historia de investigación que nos permita tomar las mejores decisiones para poder enfrentar una historia que ya de por sí es grande por su complejidad o incertidumbre.

Ejemplo: Sincronizar un desarrollo con un sistema legado con el que nunca  se ha trabajo, podría generar una historia bien pesada y cuyo éxito se encuentra lleno de riesgos, o podría generar una SPIKE de investigación para validar si dicho sistema es compatible con el desarrollo actual.

PATH

Hacer un Slicing por flujo o camino, indica que debemos priorizar la ruta más escogida o que más valor nos añada, y que trabajemos de manera separada las múltiples salidas o entradas que puedan surgir de este camino. 

Ejemplo: En un flujo de pago se puede hacer el pago mediante WEBPAY y con tc; solo uno sería prioridad se presentar a un usuario final.

INTERFACES

Puede referirse al tipo de dispositivo, navegador, o aplicación que se utilice para acceder a nuestras funcionalidades. Para esto, se debe priorizar el que más valor le entregue al negocio.

Ejemplo: Un sistema que debe funcionar tanto en la web (todos los navegadores) como en una aplicación Mobile (todos los os) ¿Es necesario que al momento de lanzar nuestra aplicación funcione en absolutamente todos los dispositivos y navegadores?

DATOS

Todos esos campos o tipos de información que, si bien nos faciliten la vida en la interacción, son complejos de implementar en un inicio. Lo ideal sería dar prioridad a lo más universal, para luego centrarnos en lo específico.

Ejemplo: Los campos de un formulario que en primera instancia podrían ser todos de tipo TEXTO, para luego en un incremento trabajar los widgets. ¿Es necesario que el formulario sea perfecto desde un inicio?

REGLAS DE NEGOCIO

Criterios de aceptación que de la historia de usuario, es necesario hacer un buen trabajo de priorización para poder definir qué es lo que será integrado inicialmente.

Ejemplo: Un Login de Usuario que además de ser funcional, mantiene las típicas reglas de seguridad: Formato de Password, cantidad de intentos, conexión con Google, etc. ¿Es necesario completar todas esas reglas desde el inicio?