Planear un sprint

Por Mitch Lacey.Propietario, Mitch Lacey & Associates, Inc, firma consultora especializada en adopciones y mejoras de metodologías ágiles y de Scrum.

Enero de 2012

En este artículo, Mitch Lacey habla sobre tres métodos que han probado ser muy beneficiosos para muchos equipos de Agile: el modelo de Kano relativo a la satisfacción de los clientes, una serie Innovation Games por Luke Hohmann y el modelo de Relative Weighting de Karl Weiger.Cualquiera de estos le ayudará a pasar de una clasificación por prioridades aproximada del trabajo pendiente a una clasificación precisa que pondera correctamente riesgos, importancia y satisfacción del cliente.

Se aplica a

Administración del ciclo de vida de la aplicación; Team Foundation Server

En este artículo:

• Introduction

• El modelo Kano de satisfacción de los clientes

• Innovación Games

  • Podar el árbol de productos

  • Comprar una característica

• Ponderación relativa - Karl Weigers

• Conclusión

Para que su equipo ágil siga trabajando eficazmente, debe ordenar los elementos en el trabajo pendiente del producto por prioridad y después actualizar esas prioridades a medida que progresa el proyecto.Todos los trabajos pendientes del producto se deben clasificar según su prioridad según el valor empresarial y el riesgo.Al reconocer este orden de prioridad, su equipo puede mejorar el foco en las características más probables de factorizar en el éxito del producto.Un trabajo pendiente ordenado y con las prioridades establecidas repercute positivamente en el equipo y en la satisfacción del cliente, además de en sus resultados empresariales.Para obtener información acerca de los trabajos pendientes, vea Compilar y administrar el trabajo pendiente del producto, Crear o agregar al trabajo pendiente del producto y Repasar y estimar el trabajo pendiente.

Al ordenar y asignar prioridades en el trabajo pendiente del producto, debe considerar muchos factores, así como ser capaz de justificar sus decisiones.Cuando se comienza con una lista de trabajos pendientes del producto sin procesar, el proceso puede parecer casi abrumador.Afortunadamente, no tiene que ordenar a la perfección cada elemento en el trabajo pendiente inmediatamente.En El calcular, describo una técnica denominada “The Big Wall” (El gran muro), que es una forma eficaz de estimar rápidamente un trabajo pendiente del producto sin procesar y trabajar con las partes interesadas para llegar a un orden de prioridades aproximado.

Esta asignación de prioridades aproximada es un buen punto de partida y podría ser lo bastante apropiada para sus circunstancias.En algunos casos, sin embargo, es posible que desee limitar estas prioridades o alcanzar un trabajo pendiente con prioridades establecidas de forma más científica.Puede llevar a cabo esto usando muchas técnicas.En el caso siguiente, hablo sobre tres métodos que han probado ser muy beneficiosos para muchos equipos de Agile: el modelo de Kano relativo a la satisfacción de los clientes, una serie de Innovation Games por Luke Hohmann y el modelo de Relative Weighting de Karl Weiger.Cualquiera de estos le ayudará a pasar de una clasificación por prioridades aproximada del trabajo pendiente a una clasificación precisa que pondera correctamente riesgos, importancia y satisfacción del cliente.

El modelo Kano de satisfacción de los clientes

El modelo de Kano de satisfacción del cliente lo desarrolló en los años 80 el profesor Noriaki Kano de la universidad Rika de Tokio.El modelo proporciona un esquema sencillo de clasificación que distingue entre los atributos básicos y diferenciadores.Un enfoque basado en cuestionarios, el modelo es una manera eficaz de ver las características de producto y un debate estimulante para el equipo de diseño.

En Kano, realizamos una serie de preguntas de dos formas diferentes: funcional y disfuncional.Por ejemplo, digamos que se pregunta a los clientes sobre un sistema de navegación GPS para coches.Primero solicitamos la forma funcional de la pregunta:

• ¿Cómo se sentiría si este coche tuviera un sistema de navegación GPS?

Limitamos las respuestas a las siguientes:

• Me gustaría que fuera así

• Esperaba que fuera así

• Soy neutral

• Puedo vivir con ello

• No me gusta así

Para este ejemplo, supongamos que nuestros clientes ficticios respondieron “Me gusta así”.

A continuación, pedimos el formulario disfuncional de la pregunta:

• ¿Cómo se sentiría si este coche no tuviera un sistema de navegación GPS?

Los clientes ficticios pueden elegir entre cualquiera de las respuestas enumeradas.Sin embargo, la respuesta suele ser, y lo es generalmente, diferente.Para este ejemplo, digamos que los clientes ficticios respondieron “Esperaba que fuera así” al formulario disfuncional de la pregunta.

Cuando se hace esto para un proyecto real, podemos presentar esta lista de preguntas opuestas a varios grupos de clientes, es decir, distintos conjuntos de individuos que representan diferentes funciones de la organización del cliente.Podría tener un grupo de marketing, un grupo de contabilidad, grupo de fabricación, y así sucesivamente.Con el propósito de entender el modelo, sin embargo, vamos a imaginar que simplemente hacemos una pregunta de un solo grupo de cliente.Después de que compilemos los pares de respuesta (las respuestas al formulario funcional y disfuncional), lo asignamos sobre una cuadrícula, como se muestra en la Tabla 1.

Tabla 1 - Asignación de Kano

Observe que, en nuestro ejemplo, nuestros clientes ficticios respondieron me gusta a la pregunta funcional y lo espero a la pregunta disfuncional.Cuando asignamos este par a la cuadrícula, podemos ver que la intersección de esos dos atributos es una E, como el cuadrado resaltado en amarillo indica.Examinemos lo que significa para nuestro trabajo pendiente con prioridades establecidas.

• E = Excitadores.Estas son las características que el cliente no esperaba y que realmente diferencian a un producto de la competencia.Resultan difíciles de identificar, especialmente al principio, porque puede ser difícil dar con preguntas que den lugar a características emocionantes.Por esta razón, los excitadores suelen surgir y aumentar su prioridad a medida que progresa el proyecto y se empiezan a recibir comentarios del cliente.

  • Los clientes reciben gran satisfacción de estas características y están dispuestos a pagar un elevado para tenerlas.Por ejemplo, el iPod de Apple encantó a los clientes con su capacidad intuitiva de girar el contenido para adaptarse a la orientación de la pantalla.Sin embargo, la ausencia de esa característica no habría reducido la satisfacción, dado que el cliente no habría contado con ella.

  • En nuestro ejemplo, disponer de navegación GPS sería una característica interesante.Examinar esta característica, al menos hasta el punto de recibir comentarios del cliente, debería ser una prioridad relativamente alta.

• B = línea base.Estas características deben estar en el producto.Son las características imprescindibles prioritarias.

  • Con independencia de lo bien que se ejecuten estos atributos básicos, cliente permanecerá neutral respecto al producto.Un procesador de textos, por ejemplo, debe tener las funciones “crear documento” y “guardar documento”.Son el precio de entrada.

  • Si hubiéramos preguntado a nuestro grupo de clientes acerca de los cinturones de seguridad, la mayoría de las personas responderían que esperan que un nuevo venga con ellos y que les desagradaría si no fuera así.Si incorporáramos esas dos respuestas en la cuadrícula, encontraríamos que los cinturones de seguridad son una línea base (B), es una característica obligatoria.

• L = Lineal.También conocidas como requisitos de rendimiento, las características lineales se correlacionan directamente con la satisfacción del cliente.Se sitúan justo debajo de las características de línea base en cuanto a prioridad, pero se debe sopesar su costo.

  • La funcionalidad o calidad incrementadas de ejecución aumenta la satisfacción del cliente.Una funcionalidad menor reduce la satisfacción.

  • El precio del producto se relaciona generalmente con estos atributos.

• I = Indiferente.Estas características son menos importantes para el cliente y, como tales, deben ser menos importantes para el producto.Probablemente devolverán poco valor empresarial o ninguno.

La tabla 1 muestra también Q y R.

• C: Cuestionable – La pregunta es probablemente incorrecta o la respuesta es sospechosa.

• H: Hacia atrás - La combinación de respuestas no calcula.Considere el sistema de navegación GPS; si alguien responde que lo esperaba allí pero que tampoco les importaba que no estuviera, es una respuesta R.

Si un par de respuestas se clasifica con Q o R, debería comprobar las preguntas o par de respuestas más detalladamente.

Innovación Games

Innovation Games son herramientas para ayudarle a desarrollar una investigación de mercados primarios.Con estas herramientas, los clientes juegan a “juegos” con el objetivo de generar comentarios e información sobre un producto o servicio.Luke Hohmann creó y describe más de 12 de estos juegos en su libro, Innovation Games, que es fundamental en cualquier biblioteca.Mis dos juegos favoritos para obtener un trabajo pendiente con prioridades establecidas son Podar el árbol de productos y Comprar una característica, que Lucas describe en este fragmento y que sacó de ese libro (usado con permiso):

Podar el árbol de productos

Los jardineros podan los árboles para controlar su crecimiento.En ocasiones, la eliminación es artística, y terminamos con arbustos en forma de animales o con formas abstractas interesantes.En la mayoría de las ocasiones la poda tiene como objeto que el árbol esté equilibrado y que produzca fruta de alta calidad.El proceso no está diseñado para “cortar”, sino para “dar forma”. Utilice esta metáfora para ayudar a crear el producto según los deseos de los clientes.

El juego

Comience por dibujar un árbol grande en una pizarra o papel parafinado o imprimir una imagen de gráfico del árbol con formato de cartel grande.Las ramas gruesas representan las áreas principales de la funcionalidad del sistema.El borde del árbol (sus bifurcaciones más externas) representa las características disponibles en la versión actual.Escriba las nuevas características posibles en varias tarjetas de índice, idealmente con forma de hojas.Pida a los clientes que coloquen las características deseadas en torno al árbol, definiendo la siguiente fase de su crecimiento.¿Crean la estructura de un árbol que está creciendo de forma equilibrada?¿Una bifurcación, quizás una característica básica del producto, obtiene la mayor parte de crecimiento?¿Se hace más fuerte un aspecto infrautilizado del árbol?Sabemos que las raíces de un árbol (la infraestructura de soporte y atención al cliente) debe extenderse al menos tanto como la copa.¿Pasa esto con los suyos?

Árbol de producto – Hohmann

Por qué funciona

Tanto usted como los clientes saben que las características varían en importancia.Así, se tiende a desear esforzarse en las características más importantes, aquellas que proporcionan el valor máximo a los clientes.Desgraciadamente, esto significa que a veces no nos esforzamos lo suficiente en las características que son necesarias para completar el producto.El juego "Prune the Product Tree" proporciona a los clientes una manera de proporcionar entradas en el proceso de toma de decisiones examinando el conjunto de características que constituyen el producto en una forma holística.

Comprar una característica

¿Qué característica tentará a clientes a adquirir el producto?¿Qué característica hará que los clientes se actualicen?¿Qué característica dejará tan satisfechos a los clientes que pasarán por alto o tolerarán las características que desean que corrija o elimine?

Los planificadores de producto debaten constantemente estas y otro tipo de preguntas.Elegir el conjunto correcto de características para agregar a una versión marca a menudo la diferencia entre un error a corto plazo o un éxito a largo plazo.Desgraciadamente, demasiados planificadores de producto toman esta decisión sin implicar a las personas más afectadas por ella, sus clientes.El juego Comprar una característica mejora la calidad de esta decisión solicitando a los clientes que le ayuden a conseguirlo.

Comprar una característica (Sterne)

El juego

Cree una lista de características posibles y asigne un precio a cada una.Al igual que en un producto real, el precio se puede basar en los costos de desarrollo, valor para el cliente o cualquier otra cosa.Aunque el precio pueda ser el costo real que se desea aplicar a la característica, no es necesario normalmente.Los clientes compran las características que quieren en la próxima versión del producto con dinero de juego que les proporciona.Asegúrese de que algunas características tiene un precio lo suficientemente alto como para que ningún cliente las compre.Animar a los clientes a reunir dinero para adquirir características especialmente importantes y/o caras.Esto ayudará a motivar las negociaciones entre los clientes para decidir cuáles son las características más importantes.

Este juego funciona mejor con entre cuatro y siete clientes por grupo, lo que permite crear más oportunidades para que los clientes junten su dinero mediante la negociación.A diferencia del juego Caja de producto, el juego Comprar una característica se basa en una lista de características que probablemente ya aparezcan en la guía de orientación del desarrollo.

Por qué funciona

Los planificadores del producto a menudo caen en la trampa de pensar que los clientes han definido con claridad las prioridades del producto.Algunos las tienen.La mayoría no.Cuando se le presenta un conjunto de opciones, muchos clientes dirán simplemente “Las quiero todas”, y le harán responsable de la asignación de prioridades a sus solicitudes.Alternativamente, los directores de producto recopilan con frecuencia las prioridades de la característica trabajando con clientes de forma independiente y, en el proceso, y quizás sin incluso darse cuenta de ello, toman de nuevo la responsabilidad de clasificar características según su prioridad.Al comprometer a clientes como grupo y al darles una cantidad limitada de recursos, se les ofrece la oportunidad de dar prioridad a sus deseos como grupo.Pero aquí no es donde se encuentra la magia.La magia está en la estructuración de las conversaciones de modo que los clientes negocien entre ellos determinadas características.Esta negociación es la que mejora su comprensión de lo que realmente desean sus clientes.

Ponderación relativa - Karl Weigers

Otro método excelente para establecer prioridades es Relative Weighting, que introdujo Karl Weigers en 1999.Este método no solo proporciona un mecanismo para dar prioridad a los requisitos basado en los datos y los comentarios proporcionados por el usuario, sino que también las opiniones de los expertos del equipo.Como Kano e Innovation Games, Relative Weighting permite al propietario del producto mejorar el control de qué características se deben implementar y en qué orden de prioridad.

El primer paso es asignar un peso a la ventaja relativa de una característica.Un punto positivo es la ventaja para los usuarios de tener la característica en el producto final.Lo siguiente es asignar la reducción relativa.La reducción es la consecuencia de que los usuarios no tengan la característica en el producto final.(Evaluando ventajas y reducciones se consigue la misma acción que el formulario funcional y disfuncional del método de Kano de la pregunta.) Las ponderaciones son números arbitrarios que representan cómo valora su compañía las ventajas y los riesgos de las características.Es muy similar a cómo un profesor determina qué importancia conferir a los deberes, asistencia y exámenes a la hora de determinar la nota final; variará de profesor a profesor.Si decide que las ventajas tienen reducciones, haga que el peso sea mayor que la reducción en la proporción que considere adecuada.Si decide que las reducciones tienen ventajas, ajuste el peso en consecuencia.En el ejemplo del cuadro 2, conferimos a la ventaja una importancia relativa de 2 y la reducción un importancia relativa de 1, lo que significa que el marcado será factor de mayor amplitud a la hora de determinar la prioridad final.

De la misma manera, determinamos la importancia de porcentaje del costo y el porcentaje del riesgo.En el ejemplo siguiente, el riesgo no es tan importante para el proyecto, de modo que el porcentaje de costos recibió una importancia de 1 y el porcentaje de riesgos un porcentaje de 0,5.(Observe que, aunque las ventajas y restricciones se ponderan antes de que se calcule el porcentaje de valores, el coste y el riesgo se ponderan como porcentajes.) Si tiene un proyecto de alto riesgo, podría soportar un riesgo superior al costo.

Ahora que se han establecido los niveles de importancia, pedimos a los usuarios que clasifiquen el beneficio relativo y la reducción relativa de cada característica.Cada ventaja y restricción se clasifica según una escala establecida. Weigers recomienda del 1 al 9, pero podría elegir otra escala siempre que sea coherente.La ventaja relativa es el valor que la característica entregará; la reducción relativa es el potencial impacto negativo de no hacer la característica.

Por ejemplo, supongamos que una característica posible es “Hacer que el widget cumpla la normativa Sarbanes-Oxley”. No hay prácticamente una ventaja relativa para los usuarios, pero la reducción relativa para la empresa es grande: si no se cumple la empresa quedaría fuera del negocio.Como tal, puede que veamos una puntuación de 1 o 2 para las ventajas relativas y una puntuación de 8 o 9 para la reducción relativa.

En el ejemplo siguiente, los usuarios puntuaron la ventaja relativa de la característica “Estado del pedido de un proveedor” con un 5.Puntuaron su reducción relativa como 3.Para obtener el valor total de esa característica, multiplicamos los dos números por sus ponderaciones relativas y los sumamos:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

En este caso, el valor total de la característica es 13 puntos.

Cuando obtenemos el valor relativo total y el porcentaje del valor para las características, nos alejamos de los usuarios para acercarnos a la visión del equipo.Le pedimos al equipo que calcule el costo relativo de implementar cada característica utilizando la misma escala.Karl Weigers explica: “los desarrolladores calculan los índices del costo según factores como la complejidad del requisito, la cantidad de trabajo de la interfaz de usuario necesaria, la capacidad potencial de reutilizar diseños existentes o código y los niveles de pruebas y documentación necesarios”.

Después de que calculemos el costo relativo, calcularemos el riesgo relativo.Una vez más Weigers afirma: “los desarrolladores estiman el grado relativo de riesgo técnico u otro tipo de riesgo asociado a cada característica en una escala comprendida entre 1 y 9.Una estimación de 1 indica que puede estar tranquilo, mientras que 9 indica que habrá serios problemas en cuanto a la viabilidad, la disponibilidad de personal con la experiencia necesaria o el uso de herramientas y tecnologías que no se hayan probado o que resulten desconocidas.La hoja de cálculo calculará el porcentaje de riesgo total que procede de cada característica”.

Después de que anotemos los valores para las ventajas, restricciones, costo y riesgo relativos, sumamos cada columna.Estos totales se utilizarán para calcular los porcentajes.

• Porcentaje del valor total: divida el valor de la suma del beneficio relativo y la reducción entre la suma total en la parte inferior.En el ejemplo siguiente, es 13 / 154 = 8%.

• Porcentaje del costo relativo: divida el valor del costo relativo entre la suma del costo relativo total en la parte inferior.En el ejemplo siguiente, es 2 / 42 = 4,8%.

• Porcentaje de riesgo relativo: divida el valor de riesgo relativo entre la suma del riesgo relativo total en la parte inferior.En el ejemplo siguiente, es 1 / 33 = 3%.

• Prioridad: divida el porcentaje de valores por (porcentaje del costo * importancia del costo) + (porcentaje del valor * importancia del valor).En el ejemplo siguiente, sería 8,4% / ((4,8% * 1) + (3% * 0,5).Esto proporciona el valor de prioridad (1,345).

Después de que obtengamos los valores de prioridad, clasificamos la columna de prioridad en orden descendente de modo que los elementos de prioridad máxima se encuentran en la parte superior.Cuando se agregan elementos al trabajo pendiente del producto o aparece más información sobre un caso, necesitaremos volver a evaluar las prioridades.

Finalmente, la hoja tiene el aspecto de esta tabla:

Con este enfoque, puede entender mejor los intervalos que van bien para el equipo y para las partes interesadas.También ayuda a fundamentar mejor los debates porque puede ser difícil aislar objetivamente elementos como beneficios, reducciones, costos y riesgos para cada característica.

Weigers explica cómo hacer que el modelo coincida lo máximo posible con la realidad deseada:

“Calibre este modelo para su propio uso con un conjunto de requisitos o de características completos desde un producto anterior.Ajuste los factores de ponderación hasta que la secuencia calculada de prioridad se ajuste con su evaluación tras la finalización de la tarea respecto a la verdadera importancia de los requisitos en el conjunto de pruebas.Este modelo también puede ayudarle a sopesar las decisiones cuando esté evaluando propuestas de nuevos requisitos.Estimar su prioridad mediante el modelo para indicarle cómo coinciden respecto a los requisitos existentes, de forma que pueda elegir una secuencia adecuada de la implementación.Cualquier operación que puede realizar para mover el orden de prioridades de los requisitos del terreno político a un objetivo analítico mejorará la capacidad del proyecto para entregar la funcionalidad más importante en la secuencia más adecuada.”

Karl Weigers ha escrito dos libros que entran en más detalle en la importancia relativa: Software Requirements, Second Edition y More About Software Requirements: Thorny Issues and Practical Advice.

Tanto si usa uno de estos métodos como cualquier otra técnica, recuerde que el trabajo pendiente del producto es un ente vivo.No se le asignan prioridades una vez y después se deja de lado: la reasignación de prioridades es una parte esperada del mantenimiento de una lista de trabajo pendiente en buen estado.Para que el proyecto siga su ruta, debe evaluar constantemente los casos, su importancia para el proyecto, y cómo la nueva información afecta al trabajo pendiente.Debe esforzarse para que las partes interesadas y los clientes sigan implicados a lo largo del proyecto.Además, debe recordar que la estimación de un elemento es esencial para determinar su prioridad.No deje que sus trabajos pendientes queden obsoletos e inactivos.Invierta tiempo y esfuerzos en la consolidación y preparación del trabajo pendiente, verá los resultados no solo en el producto final, sino también en la línea base.

Vea también

Conceptos

Introducción al equipo

Iteraciones y planeación de Agile

Comentarios de interés de la solicitud y el proceso mediante Team Web access

Realizar un seguimiento del trabajo y administrar el flujo del mismo

1. Requisitos de Agile Software, Dean Leffingwell, Addison Wesley

   “Attractive Quality and Must-be Quality” Noriaki Kano, Quality JSQC, Vol.14, Nº 2, octubre de 1984.El artículo original de Kano.

2. http://www.processimpact.com/articles/prioritizing.html