Tema Métricas y estimaciones

Tema Métricas y estimaciones | 1

 TABLA DE CONTENIDO

INTRODUCCIÓN .............................................................................................................................. 3

TÉCNICAS DE ESTIMACIÓN SOBRE LA PLANIFICACIÓN DE TAREAS O HISTORIAS DE USUARIO ... 6

Series numéricas con crecimiento exponencial. Serie de Fibonacci. ..................................... 7
Planning Poker ...................................................................................................................... 10
T-SHIRT Sizing (XS – S- M – L – XL- XXL) ............................................................................... 13
Otras técnicas ....................................................................................................................... 14

TÉCNICAS DE PRIORIZACIÓN SOBRE LA PLANIFICACIÓN DE TAREAS O HISTORIAS DE USUARIO

...................................................................................................................................................... 14
Dot Voting ............................................................................................................................. 15
MoSCoW ................................................................................................................................ 15
Modelo de Kano ..................................................................................................................... 16
Matriz de decisión de Eisenhower ........................................................................................ 19
Otras técnicas ....................................................................................................................... 20
Planning Poker para priorización .......................................................................................... 20

MÉTRICAS DE CUMPLIMIENTO DE PRODUCTO TERMINADO. ....................................................... 20

WIP ........................................................................................................................................ 20
Diagrama de Flujo Acumulado (DFA) .................................................................................... 21
Burn-down chart y Burn-up chart ......................................................................................... 23

BIBLIOGRAFÍA ............................................................................................................................... 24

Tema Métricas y estimaciones | 2

Introducción

Dentro de los aspectos más importantes de las metodologías ágiles se encuentran los roles, los
procesos (donde destacan planificación, desarrollo y reuniones) y los conceptos generales.

Uno de los conceptos principales, independientemente de la Metodología Ágil a utilizar, es el de

Historia de Usuario, principalmente con SCRUM y XP.

Recordamos que en SCRUM, todos los requerimientos que define un cliente en un momento en
particular para construir un producto final, se agrupan en el Product Backlog. Si el cliente
detecta que necesita nuevos requisitos según avanza el desarrollo del proyecto, se van
añadiendo al Product Backlog, haciendo que éste, sea dinámico.

Es importante tener en cuenta, que el Product Backlog, se descompone en requisitos

funcionales, que se denominan Historias de Usuario y Requisitos No funcionales.

Si una Historia de Usuario es demasiado grande y no puede realizarse en un intervalo de una

iteración (Spring denominada en SCRUM), se divide en Historias de Usuario más pequeñas que
se agrupan en lo que se denominan Épicas y las Épicas a su vez, se pueden agrupar en Temas.

En XP, el concepto de Historia de Usuario, también hace referencia a los requisitos que el cliente
quiere que se implementen en el producto final, y, cuyo dinamismo dentro de la metodología,
fomenta que, se indique cada periodo temporal definido, generalmente en un número pequeño
de semanas, en qué Historias debe el equipo trabajar, completando en todo momento el análisis
previo, el diseño sobre el análisis realizado, el desarrollo y las pruebas.

En otras metodologías ágiles, como Kanban, se utiliza el concepto de tareas, semejables a

Historia de Usuario, y se suelen mostrar en un tablero, organizadas según se ve a continuación:

TAREAS POR HACER TAREAS EN PROGRESO TAREAS HECHAS

Ilustración : Tabla tareas Kanban

Tema Métricas y estimaciones | 3

Este tablero es habitualmente usado en Kanban, aunque también se puede usar en SCRUM o XP

Incluso este tablero Kanban, en algunas organizaciones, se divide en un número más detallado
de columnas, incluyendo, IDEAS/TAREAS POR HACER/TAREAS EN PROGRESO (EN DESARROLLO,
EN PRUEBAS), TAREAS HECHAS (EN VALIDACIÓN, VALIDADAS).

IDEAS TAREAS POR TAREAS EN PROGRESO TAREAS HECHAS

HACER EN DESARROLLO EN EN VALIDACIÓN
PRUEBAS VALIDADA

Ilustración : Tabla tareas Kanban ampliada

Las tareas, van pasando de una columna a otra según va avanzando el proyecto.

Las Historias de Usuario o tareas, en resumen, son una descripción sencilla y resumida de un
requerimiento o requisito en el lenguaje del cliente.

Una Historia de Usuario debe tener las siguientes características según el método INVEST:

I: Independent (Independiente): debe ser completamente necesaria por sí misma, y sin

depender de otras Historias de Usuario. Se debe poder llevar a cabo sin ser necesario
realizar otras.

N: Negotiable (Negociable): una Historia de Usuario que no se ha empezado a acometer

puede ser modificada tantas veces como se necesite por parte del cliente.

V: Valuable (Valiosa): debe conllevar un aporte significativo de valor para el cliente y para
el negocio.

E: Estimable (Estimable): debe poder estimarse el tiempo y el esfuerzo en el desarrollo

de su realización por parte del equipo de trabajo.

Tema Métricas y estimaciones | 4

 S: Small (Pequeña): se debe poder implementar en un valor temporal pequeño o iteración,
siendo priorizada.

T: Testable (Verificable): debe conllevar implícitamente la realización de pruebas para

comprobar que satisface las necesidades del cliente y validar que se ha terminado el
desarrollo.

Una vez definidas e identificadas las Historias de Usuario, se debe estimar el esfuerzo para
poder completarlas y priorizarlas, manteniendo la lógica dentro del desarrollo del producto o
solución. Es decir, se debe conseguir el equilibrio de satisfacer las necesidades de priorización
marcadas por el cliente, con la ejecución en una línea temporal lógica y acorde a una estimación
realista de los esfuerzos identificados.

Por ejemplo: un cliente requiere la ejecución de un proyecto de construcción de un portal para

la visualización de videos por internet conectando con varias plataformas de streaming, donde
su mayor prioridad es que los usuarios busquen correctamente a partir de parámetros de
búsqueda. La lógica indica que como requisito previo, primero debemos crear una interfaz
donde el usuario haga login y se guarden sus datos cumpliendo la normativa legal de protección
de datos. Es posible que el esfuerzo de cumplir ese requisito previo, que el cliente no ha
especificado, requiera un esfuerzo que debe realizarse previamente a la implementación del
sistema de búsqueda, y este esfuerzo pueda ser superior.

En Metodologías Ágiles, para poder priorizar las tareas o Historias de Usuario, existe el concepto
de Valor de Negocio (sus siglas en inglés BV), y para poder estimar el esfuerzo de las Historias
de Usuario, existe el concepto de Puntos de Historia (SP en sus siglas en inglés).

El Valor de Negocio, permite conocer la prioridad que le asigna a cada tarea o Historia de
Usuario el cliente final. Si el cliente no realiza esta priorización de manera clara, será el propio
equipo de trabajo el que deba hacerlo mediantes técnicas que se verán a lo largo del desarrollo
del presente tema.

Los Puntos de Historia representan el esfuerzo que se estima para realizar una Historia de
Usuario o tarea en particular, teniendo en cuenta:

Complejidad del trabajo a realizar dentro de la Historia de Usuario.

Incertidumbre y riesgo en la ejecución de la Historia de Usuario.

Tema Métricas y estimaciones | 5

 Volumen de trabajo que representa la propia Historia de Usuario.

Por lo general, los Puntos de Historia son medidas propias de cada equipo, y no suelen ser
utilizadas para comparar entre diferentes equipos.

Por ejemplo: si una persona de un equipo realiza una historia de usuario en particular que
consiste en desarrollar parte de una aplicación, al realizarla otro miembro de otro equipo, puede
encontrarse con una incertidumbre distinta, ya que la velocidad de desarrollo y la experiencia
de cada uno será distinta.

Actualmente, existen 2 tendencias para poder medir el progreso en marcos de trabajo ágil:

1. La primera de ellas está basada en la ejecución de puntos de historia, porque el Manifiesto

Ágil expone que: “la simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado es esencial”.
2. La segunda de ellas está basado en producto terminado. Según se expone también en el
Manifiesto Ágil, “Valorar más el software (producto) que funciona” y “El producto cerrado
funcionando es la medida principal del progreso”.

Ambas, pueden ser perfectamente válidas, no obstante, antes de ejecutar, y como se ha

revisado previamente en las características se debe realizar una estimación y una
priorización.

Las estimaciones son fundamentales para el éxito de cualquier proyecto, independientemente

de que éste se gestione mediante metodologías tradicionales o metodologías ágiles. Es
importante realizar estimaciones en todo el ciclo de vida del proyecto, tanto en la planificación
como en el valor del cumplimiento.

Técnicas de estimación sobre la

Planificación de tareas o Historias de
Usuario

Durante la ejecución de un proyecto con metodologías ágiles, planificar la siguiente iteración

mediante estimación de Puntos de Historia sobre las tareas o Historia de Usuario que serán

Tema Métricas y estimaciones | 6

entregadas permite tener una guía para:

1. Tomar decisiones.
2. Asignar recursos
3. Realizar una planificación temporal de versiones de un determinado producto.
4. Elaborar presupuestos

Los Puntos de Historia no proporcionan una medida absoluta exacta del tamaño de una tarea o
Historia de Usuario, sino su tamaño relativo a otras tareas o Historias de Usuario. Tampoco
miden tiempo, sino tamaño relativo.

Por ejemplo: ¿20 km es mucha o poca distancia?

Si lo comparo con 30 metros, si es mucho, pero si lo comparo con la distancia de Madrid a

Bogotá de aproximadamente 8.000 km, relativamente hablando es poca distancia.

No hay una relación única lineal entre el tamaño de los puntos de historia de una tarea o
Historia de Usuario y su duración en tiempo de ejecución, ya que este último, depende de varios
factores, como son: tamaño en cuanto a volumen de trabajo en particular, número de personas
que la ejecutan, experiencia de las propias personas, volumen de trabajo que manejan y,
aspectos incluso emocionales de los profesionales que la realizan como son intuición,
creatividad o incluso la motivación.

¿Se podría atender a realizar estimaciones para la ejecución de proyectos con tamaños
absolutos? La realidad es que sí, no obstante, se utilizarían otros conceptos denominados
Puntos Función, y que están más orientados al desarrollo de software.

A continuación, se exponen las técnicas de estimación más habituales para establecer el valor
de los Puntos de Historia de las Historias de Usuario:

Series numéricas con crecimiento exponencial. Serie de

Fibonacci.

Desarrollo de la técnica: El equipo de trabajo se reúne con el fin de poder dar un valor de Puntos
de Historia a cada Historia de Usuario o tarea, usando el concepto comentado anteriormente de
que no hay una relación lineal, y por ello los saltos entre las tareas con menores valores es más
corto que los más grandes. Es decir, la relación de estimación de una Historia de Usuario o

Tema Métricas y estimaciones | 7

tareas no es:

Ilustración : Relación de incremente lineal

Sino que la relación cumple la serie de Fibonacci, con el fin de que se pueda representar la
diferencia entre saltos entre la dificultad, incertidumbre y volumen para los Puntos de Historia
de unas tareas y otras, y con valores acotados hasta un máximo valor:

Tema Métricas y estimaciones | 8

Ilustración : Relación de incremento Serie Fibonacci

En la reunión se deben repasar cada una de las Historias de Usuario, y se va dando un valor por
cada miembro, y, si hay mucha diferencia de criterios, se debe alcanzar un consenso entre
todos los miembros del equipo, justificando cada uno su posición, con el fin de dar valor de
Puntos de Historia único a cada Historia de Usuario.

Esta técnica, permite evitar el valor sesgado que pueda dar cada miembro del equipo teniendo
en cuenta experiencias o estimaciones previas realizadas de manera individualizada. Es decir,
un miembro del equipo puede poseer demasiada información previa, que pueda viciar una
decisión de la estimación de una tarea para todo el equipo.

Es importante destacar que, las cifras de la serie de Fibonacci que expone cada miembro del
equipo para cada Historia de Usuario o tarea, se deben plantear de manera simultánea para que
cada persona del equipo pueda pensar de manera independiente en base a su revisión personal.

Esta tarea es mucho más sencilla realizarla con estos valores que con una serie lineal. En el

Tema Métricas y estimaciones | 9

siguiente artículo se puede observar un relato de Mike Cohn, uno de los contribuidores más
importantes sobre las metodologías ágiles justificando la elección:

https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimat
ing

Pero dentro de las series numéricas y en particular la de Fibonacci, existen deficiencias

importantes, que pretende resolver la técnica de Planning Poker.

Resultados alcanzados: consenso total entre los miembros del equipo dando valores de Puntos
de Historia a cada Historia de Usuario con valores relativos no lineales. Transmisión de
información al cliente, de los valores de cara tarea.

Planning Poker

Es una técnica basada en gamificación, que introduce pequeñas modificaciones a la vista

anteriormente de Fibonacci, para calcular estimaciones de Puntos de Historia a través del
consenso del equipo.

El concepto es el mismo que el anterior, tipificando los valores de la serie de Fibonacci en una
baraja de cartas, más distintos símbolos adicionales que se verán a continuación, y que se
reparte a cada miembro del equipo.

Se realiza una reunión del equipo de trabajo para poder estimar los Puntos de Historia de las
Historias de Usuario en base al siguiente procedimiento:

Uno de los miembros del equipo hace las labores de facilitador, exponiendo el conjunto de
Historias de Usuario a estimar y el valor de medida que se determina, que por lo general, son
Puntos de Historia.

Se recomienda en todo momento tener un tiempo para cada una de las tareas o Historias de
Usuario con el fin de que no se alargue indefinidamente.

1. Tras exponer el conjunto de todas ellas, se comienzan a revisar una a una. El facilitador
expone la primera, con todos los datos que tiene sobre ella, y los miembros del equipo
pueden realizar preguntas sobre la misma y realizar una breve discusión para lograr una
mayor claridad en la exposición.

Tema Métricas y estimaciones | 10

 2. Cada miembro del equipo, tiene una baraja de cartas ya sea física o digital (mediante
aplicación software), para poder, de manera simultánea, exponer el valor que estima de
cada Historia de Usuario en base a sus consideraciones.
3. Cada miembro del equipo, por cada Historia de Usuario que se plantea, selecciona una de
las cartas dejándola boca abajo y en el momento que el facilitador permite descubrir la
carta, se realiza de manera simultánea por todos los miembros del equipo.
4. Si la diferencia entre las cartas más alta y más baja es significativa, se exponen las
justificaciones oportunas por cada miembro, debiendo realizar de nuevo el proceso de
selección entre todos los miembros, debiendo llegar a un consenso.
5. Este proceso se realiza por cada una de las Historias de Usuario hasta llegar a su
totalidad.

Una vez conociendo los Puntos de Historia de todas las Historias de Usuario, se deben priorizar
según las necesidades del cliente para su posterior ordenación en iteraciones a desarrollar.

La técnica de Planning Poker, como se ha comentado anteriormente, tiene algunas diferencias

con la expuesta en el punto anterior de Fibonacci, basadas principalmente en la introducción de
códigos adicionales en la baraja de cartas a utilizar. Esto es, la baraja de cartas contiene lo
siguiente:

Cada carta de la baraja tiene un número de la serie de Fibonacci acotado hasta un cierto
valor.

Tema Métricas y estimaciones | 11

Ilustración : Cartas de Baraja Planning Poker numéricas

Como aspectos diferenciales más importantes, con respecto a Fibonacci, se incluye el valor de
infinito en una de las cartas, simulando que esa tarea es demasiado grande y el equipo
considera que no se puede realizar o que incluso se debe valorar la segmentación de la misma.

Además, se incluye el valor de 0 puede significar que el trabajo ya está realizado o que el
esfuerzo es muy liviano para poder tenerlo en cuenta, y el valor de ½, que igualmente supone
tareas cuyo desarrollo supone un esfuerzo ínfimo y sin apenas incertidumbre.

Además, también se tienen cartas con símbolos que el equipo puede extraer y que
suponen una diferencia con respecto a la técnica anterior:

Ilustración : Cartas de Baraja Planning Poker no numéricas

La carta con el símbolo “?” sugiere una incertidumbre completa y que no se es capaz de
dar un valor.

El símbolo de “la taza” sugiere la necesidad de un descanso dentro de la reunión del

planning póker.

Resultados alcanzados: son mejoradas con respecto a los obtenidos con la aplicación de la serie
de Fibonacci, permitiendo exponer una serie de símbolos que incluyen la posibilidad de
trasladar incertidumbre al equipo de trabajo, o necesidad de descanso que permita no hacer
estimaciones que se dejen llevar por el deseo de finalización temprana.

Tema Métricas y estimaciones | 12

T-SHIRT Sizing (XS – S- M – L – XL- XXL)

Es una técnica usada en metodologías ágiles para estimar el tamaño relativo de tareas o
Historia de Usuario, utilizando por analogía las tallas de las camisetas.

Una XS representa una Historia de Usuario muy pequeña, y una XXL será la más grande.

Se suele utilizar para equipos de trabajo menos maduros en el uso de metodologías ágiles, y
facilita su transmisión desde el equipo de trabajo al cliente, a través del enlace (en SCRUM sería
el Product Owner). Con esta técnica, el cliente puede imaginar qué supone una tarea de un
tamaño u otro por analogía de manera cualitativa.

No obstante, este método no está muy extendido por lo que realizar comparativas por analogía,
aunque ya de por sí, es complejo en las metodologías ágiles porque no hay 2 equipos de trabajo
iguales, el uso de esta técnica lo descarta del todo.

Por otro lado, esta técnica, puede dar a entender que el incremento pueda ser lineal, ya que se
va subiendo una talla ante dificultad de Historia de Usuario o tarea, cuando la realidad es que
no es así, y precisamente la serie de Fibonacci es la que más se acerca a un valor cuantitativo
de la realidad en el entorno Ágil.

Por otro lado, en entornos profesionales, al transmitir el valor de los trabajos a realizar como
tareas XS, XL o M, aunque puede ser más entendible para los clientes, puede quedar menos
profesional.

Resultados alcanzados: los resultados son menos fiables y robustos que con las técnicas
anteriores, ya que no dan un valor numérico como tal. No obstante, en muchos equipos de
trabajo, se realiza una relación entre las tallas y un valor de la serie de Fibonacci que veíamos
en las técnicas comentadas para facilitar la introducción a los tipos de estimación más comunes
en Metodologías Ágiles.

Este hecho, permite paliar varias de las deficiencias comentadas arriba, y por otro lado, va
introduciendo al equipo a la técnica más comúnmente frecuentada

Tema Métricas y estimaciones | 13

Otras técnicas

Además de las ya revisadas, también existen otras posibilidades por analogía a las tallas de
camisetas, y estas, pueden ser razas de perros, como ya en su día Mike Cohn, uno de los
contribuidores más importantes al uso de metodologías ágiles, usó para relativizar los
problemas. Posteriormente, también le daría un valor a cada raza de perro, por lo que era más
fácil exponer valores para cada problema o tarea que se le presentaba.

Técnicas de priorización sobre la

Planificación de tareas o Historias de
Usuario

En las metodologías ágiles, generalmente se utiliza una figura dentro del equipo de trabajo, que
es el facilitador, (por ejemplo, en SCRUM es el conocido como Product Owner), y que permite
hacer de interlocutor con el cliente, para conocer los objetivos principales y sobretodo la
priorización de los mismos.

Es decir, traslada la priorización de las necesidades de negocio al equipo de trabajo, que debe
reflejarla en las Historias de Usuario para, en base al orden marcado por el cliente, alcanzar el
producto final.

En muchas ocasiones, estos objetivos en cuanto a alcance, están parcialmente o poco definidos,
y, por otro lado, en muchos proyectos, esta traducción de necesidades de negocio a épicas,
temas e Historias de Usuario o tareas, no tiene una fácil relación unívoca y se debe aplicar una
lógica técnica en la construcción del producto, que deriva en una priorización propia del equipo
de trabajo.

Priorizar es fundamental para:

Implementar las funcionalidades más importantes de un proyecto y que aportan un mayor

valor de negocio antes que otras que no se consideren tan necesarias.

Realizar un plan de entregas que permita cumplir con uno de los objetivos más
importantes de las metodologías ágiles y es, la entrega continua de producto (Versiones)

Tema Métricas y estimaciones | 14

 al cliente, con estas funcionalidades priorizadas por el propio cliente.

Para poder realizar esta priorización durante la ejecución de un proyecto se pueden utilizar
varias técnicas:

Dot Voting

Los participantes realizan una votación sobre la importancia y priorización de diferentes tareas
empleando distintas posibilidades, como por ejemplo, etiquetas con números limitados (del 1 al
5), pegatinas de colores o marcas de bolígrafo realizadas sobre una determinada opción.

La idea es, exponer en un tablón o pizarra las opciones listadas que existen en cuanto a
priorización de tareas, y cada miembro del equipo va incluyendo sus pegatinas, marcas de
bolígrafo (con un máximo permitido) o numeración, en función de su opinión.

Resultados alcanzados: se consigue realizar una priorización de las tareas o Historias de Usuario
en función de la opinión del equipo de trabajo si no se tiene información clara del cliente.

MoSCoW

Desarrollo de la técnica: en este caso, directamente se clasifican las características de un

producto (que dan lugar a tareas o Historias de Usuario) en cuatro categorías:

M: MUST: El producto o servicio a realizar debe tener esta característica necesariamente,

sin la cual, el producto final quedaría incompleto y el proyecto no se finalizaría
correctamente.

S: SHOULD HAVE: El producto o servicio debería tener esta característica, que es de alta
prioridad, aunque no completamente imprescindible, pero sí con un valor importante para
el cliente.

C: COULD HAVE: El producto o servicio podría no tener esta característica, deseable por el
cliente, pero no sería necesaria.

W: WON´T: características que son descartadas en un momento inicial del proyecto,

aunque no se pueden eliminar del todo, porque en un momento dado para el cliente
pueden pasar a otra prioridad.

Tema Métricas y estimaciones | 15

La priorización consiste en que, los integrantes del equipo de trabajo, deben asociar las tareas o
Historias de Usuario a una de las letras arriba mostradas. M-S-C-W.

Por lo general, el facilitador debería tener un papel importante en esta reunión de priorización,
ya que hace de enlace con el cliente para las dudas que puedan surgir ante cualquier
característica a priorizar.

Resultados alcanzados: se consigue realizar una priorización de las tareas o Historias de Usuario
en función de las características de un producto, la necesidad del cliente y en base a la opinión
del equipo de trabajo.

Modelo de Kano

Esta técnica sirve para mejorar la satisfacción del cliente con el producto que se va a entregar
en base a una relación de 5 características del producto que define el Modelo de Kano:

Características básicas, esperadas o imprescindibles: es lo mínimo esperado con lo que

debe contar el producto tras la finalización del proyecto. Es decir, si no están, el producto
no es satisfactorio para el cliente, pero si están, el cliente daba por hecho que debían
estar incluidos.

Ejemplo En los coches podemos verlo en el aire acondicionado o la radio. En los móviles
actuales, que pueda navegar por internet, y que permita la instalación de aplicaciones básicas.

Añadir estas características a los productos no va a sorprender a los clientes, no les causa
satisfacción ni las buscan activamente, pues las dan por incluidas. Si no estuvieran, el cliente se
sorprendería negativamente rechazando el producto.

Estas características no hacen más competitivo al producto, pero su ausencia prácticamente lo

saca del mercado.

Características deseadas o lineales: son las que producen mayor agrado al cliente, aunque
no tendrían por qué estar, pero sí es un valor añadido con respecto a los competidores.

Tema Métricas y estimaciones | 16

Ejemplo: La potencia de un coche: Es una característica lineal para muchos compradores de
vehículos, que prefieren coches potentes y ágiles de conducir, todos aquellos que no cumplen
sus expectativas de potencia son descartados.

Siguiendo con el ejemplo de los coches, podemos ver un factor lineal también en el consumo de
combustible: Muchos consumidores buscan bajos consumos para ahorrar y por conciencia
ecológica, un coche que ofrezca altos consumos será rechazado y los que más bajo consumo
ofrezcan se convertirán automáticamente en el objetivo de estos clientes.

Dentro de los móviles podríamos poner como ejemplo el tamaño de almacenamiento de los
datos o el tamaño de la pantalla

Características emocionantes o atractivas: son las que producen mayor sentimiento de

motivación al cliente. No esperaba encontrarlo, pero son muy valorables por el propio
cliente al encontrárselas.

Ejemplos: Los faros LED de los coches: Empezaron siendo un atributo de entusiasmo, los
consumidores no se esperaban este tipo de faros, que consumen menos, duran más e iluminan
mejor. Pero una vez testado su éxito, pronto todas las compañías los añadieron a sus coches,
empezando por las gamas altas, pero paulatinamente bajando a las medias, hasta que se ha
convertido un factor lineal.

Otro ejemplo puede ser la cámara en el frontal de los móviles para “selfies”: Inicialmente
esperamos una cámara en el móvil, pero encontrarse con dos cámaras, facilitando así que
puedas ver cómo quedas en las fotografías fue toda una novedad de impacto. Hoy en día, la
cámara frontal viene prácticamente en todos los móviles del mercado, de esta forma, un factor
que hace tiempo era clasificado como factor de entusiasmo, hoy en día, ha pasado a clasificarse
como un factor básico

Características indiferentes: no producen ninguna sensación en el cliente. Podrían estar o

no estar, que el cliente no le da importancia a ello.

Características rechazables o reversibles: son apreciadas por el cliente como negativas y

se deben revertir porque afecta negativamente a la satisfacción del cliente.

La priorización consiste en identificar cuáles tareas o Historias de Usuario son de un tipo de

característica u otro; debiendo priorizar todos los básicos, y posteriormente ir incluyendo

Tema Métricas y estimaciones | 17

algunos lineales y algún emocionante. Además, se debe atender también a las reversibles y
valorar el impacto que tiene su cambio.

Esta priorización, requiere de interactuación constante con el cliente a través del facilitador,
incluso realizando encuestas a varios clientes en función del proyecto a ejecutar, con preguntas
funcionales y disfuncionales, así como conocer la importancia para los propios clientes:

Importancia: “¿Es importante para ti esta (característica) y cómo y cuánto?”

Preguntas funcionales: “Si tuvieras esta (característica), ¿Cómo lo valorarías?” / “¿Cómo

valorarías personalmente si el producto sí tuviera esta (característica)?”

Preguntas disfuncionales: “Si NO tuvieras esta (característica), ¿Cómo lo valorarías?” /

Cómo valorarías personalmente si el producto NO tuviera esta (característica)?”

Obteniendo 5 respuestas posibles de las preguntas funcionales y disfuncionales: Me gusta/ Lo

esperaba / Indiferencia / Podría ser válido / No me gusta. Y un valor del 1 al 5 de la importancia.

La clasificación del Modelo de Kano en función de las características del producto sigue la
siguiente matriz:

PREGUNTA DISFUNCIONAL

ME GUSTA LO ESPERABA INDIFERENCIA PODRÍA SER NO ME GUSTA

VÁLIDO

PREGUNTA ME GUSTA CUESTIONABLE EMOCIONANTE EMOCIONANTE EMOCIONANTE LINEALES

FUNCIONAL
LO ESPERABA RECHAZABLES CUESTIONABLE INDIFERENTE INDIFERENTE BÁSICAS

INDIFERENCIA RECHAZABLES INDIFERENTE CUESTIONABLE INDIFERENTE BÁSICAS

PODRÍA SER RECHAZABLES INDIFERENTE INDIFERENTE CUESTIONABLE BÁSICAS

VÁLIDO

NO ME RECHAZABLES RECHAZABLES RECHAZABLES RECHAZABLES CUESTIONABLE

GUSTA

Ilustración : Matriz Preguntas y características Modelo de Kano

Posteriormente, se debe hacer la relación de las preguntas realizadas con las Historias de
Usuario o tareas planteadas para su priorización.

Tema Métricas y estimaciones | 18

En el caso de SCRUM, incluso se puede subir a nivel de Épicas o temas, para agruparlos y a
partir de ese escenario, decidir el orden de desarrollo de épicas o temas, en función de que
tengan mayor número de características básicas en primer orden.

Resultados alcanzados: igualmente que con el modelo de MoSCoW, se consigue realizar una
priorización de las tareas o Historias de Usuario en función de las características de un producto
y priorizando las necesidades del cliente, aunque en este caso, ahonda y estudia de una manera
más exhaustiva estas necesidades con respecto a MoSCoW. Es decir, pone de lleno el foco en la
priorización realizada por el cliente. Además, se puede aprovechar toda la información recaba,
no solo para priorizar, sino también para orientar la estrategia de marketing futura.

Matriz de decisión de Eisenhower

También se denomina matriz urgente/importante. Se trata de clasificar las tareas en urgentes o

importantes en función de cuatro categorías.

Posteriormente El empresario Stephen Covey popularizó el principio de decisión de Eisenhower

en su libro Los siete hábitos de las personas altamente efectivas. En este libro, Covey creó una
matriz de decisiones para ayudar a las personas a distinguir entre lo que es importante y lo que
no lo es, y lo que es urgente y no urgente

URGENTE NO URGENTE

IMPORTANTE HACER (URGENTE E PLANIFICAR (NO URGENTE PERO

IMPORTANTE) IMPORTANTE)

NO IMPORTANTE DELEGAR (URGENTE PERO DESECHAR INCLUSO ELIMINAR

NO IMPORTANTE) (NO URGENTE Y NO IMPORTANTE)

Ilustración : Matriz Covey

Se expone más información en la página web de CEREM:

https://www.cerem.es/blog/que-hacemos-primero-lo-urgente-o-lo-importante

Resultados alcanzados: priorización de las tareas a realizar ya sea por el equipo de trabajo o
directamente por el cliente, para aumentar la productividad y optimización de la gestión del

Tema Métricas y estimaciones | 19

tiempo. La decisión de lo que es urgente o importante, se debe obtener directamente del
cliente, pero, en caso de que la información no sea clara o priorice todo como urgente, debe ser
el equipo de trabajo el que haga una revisión, principalmente sin la información del cliente, para
posteriormente contrastarla y llegar a la toma de decisión final.

Otras técnicas

Planning Poker para priorización

En ocasiones, se ha determinado en algún equipo de trabajo de metodologías ágiles la

posibilidad de priorizar en base a la técnica de Planning Poker, y es correcto, teniendo en cuenta
que no deja de ser un método de opinión en base a criterios del propio equipo de trabajo, pero
en este caso, en lugar de estimación como se veía en el apartado anterior, para priorización.

Métricas de cumplimiento de producto

terminado.

WIP

WIP es Work In Progress (Trabajo en en proceso), y muestra las tareas que se están ejecutando
en un determinado momento temporal. Realiza un fotograma temporal de la capacidad de
trabajo de un equipo en un momento determinado.

Apoyándonos en los tableros utilizados en metodología ágiles que veíamos en el apartado de

introducción, sobre el estado de las tareas, en la columna de tareas en progreso, existe un
máximo de tareas a tener en progreso por parte del equipo de trabajo que se debe respetar.

IDEAS TAREAS POR TAREAS EN PROGRESO TAREAS HECHAS

HACER EN DESARROLLO EN EN VALIDACIÓN
PRUEBAS VALIDADA

Tema Métricas y estimaciones | 20

Ilustración :Tabla tareas Kanban ampliada

En el caso de SCRUM, se definen un máximo de Puntos de Historia que se pueden realizar por
iteración para mantener un ritmo constante de trabajo, y por ello se estiman las Historias de
Usuario o tareas cuyo valor sumen los Puntos de Historia a incluir en cada iteración, para
mantener un ritmo constante.

Por ejemplo, si tengo que realizar 4 tareas y la primera tarea me conlleva 7 Puntos de Historia,
la segunda me conlleva 13 Puntos de Historia, la tercera me conlleva 8 Puntos de Historia y la
cuarta me conlleva 9 Puntos de Historia; y el ritmo de trabajo son 20 Puntos de Historia cada 2
semanas, las primeras dos semanas realizaré la 1 y la 2, y a partir de la tercera semana la 3 y la
4, porque el ritmo de trabajo en progreso de mi equipo, me limita claramente.

En resumen, gracias a marcar un máximo de avance para el equipo de trabajo, y a medir el

cumplimiento del mismo, se puede informar al cliente de cómo avanza el proyecto, de cómo
avanzará el proyecto en función de los requisitos que se van incluyendo y sobretodo, permite al
equipo de trabajo, evadirse de todas las tareas que se incluyen en la columna de “POR HACER”,
porque por muchas tareas que se incluyan, el ritmo es el que es.

Diagrama de Flujo Acumulado (DFA)

Se utiliza en metodologías ágiles para visualizar y controlar de una manera más general, y no
solo de las tareas en curso, los siguientes ítems de manera gráfica:

Las tareas o Historias de Usuario que quedan en la entrada por hacer.

Las tareas en curso.

Tiempos de entrega de las tareas ya realizadas. Desde que el cliente transmite la

necesidad al facilitador, se pone en cola y se termina.

Tiempo de ciclo: tiempo desde que el equipo se pone a trabajar hasta que se entrega, sin
contar el tiempo que está en cola.

Tema Métricas y estimaciones | 21

Mediante este Diagrama de Flujo Acumulado, se ve la estabilidad del avance del equipo de
trabajo y la eficiencia del mismo.

Ilustración : Diagrama de Flujo acumulado. Fuente: https://scrum.menzinsky.com/

Si las gráficas, se estrechan de repente, es que tengo mayor capacidad de realización de trabajo
de lo necesario, ya que hay menos entrada de necesidades que rendimiento del equipo de
trabajo. Es importante dimensionar el equipo según las necesidades.

Por otro lado, si se ensancha, es que está ocurriendo que entran muchas tareas nuevas, y que
comienzo nuevas tareas sin terminar las que están en proceso, y no se prioriza correctamente.

En resumen, da una visión más amplia del proyecto que las WIP.

Tema Métricas y estimaciones | 22

Burn-down chart y Burn-up chart

Ambos se utilizan en metodologías ágiles para mostrar la evolución del trabajo realizado en una
iteración o para el proyecto completo.

El eje horizontal muestra la evolución temporal, y el eje vertical muestra Puntos de Historia.

En el Burn-down chart , teniendo en cuenta que las iteraciones son constantes en cuanto al
desarrollo de Puntos de Historia durante el tiempo, es decir, en la realización de un proyecto, se
realizan iteraciones de 20 Puntos de Historia cada 2 semanas; se traza una línea recta como
evolución ideal de la iteración, teniendo en cuenta el número de Puntos de Historia inicial, y que
llega al cero al final de la iteración, y por otro lado, se va exponiendo en la gráfica la evolución
real día a día de los Puntos de Historia que quedan por finalizar para ver exactamente la
desviación o el cumplimiento.

Ilustración : Diagrama Burn-down chart

En el Burn-up chart, la línea ideal, la marca el número de Puntos de Historia que hay que
alcanzar al final de la iteración, y se va marcando día a día la evolución de cuántos se van
completando.

Ilustración :Diagrama Burn-up chart

La diferencia principal entre ambos, es a la hora de tener el diagrama para todo un proyecto, y
se solicitan cambios por parte de los clientes. Estos cambios, suponen la inclusión de nuevas
Historias de Usuario, y por ello, estimar sus Puntos de Historia para incluirlos en el alcance.
Visualmente, se puede observar cómo se representa mejor en el burn-up que en el burn-down.

A continuación se muestran los Cambios en el Diagrama burn-down chart:

Tema Métricas y estimaciones | 23

Ilustración : Diagrama Burn-down chart con modificaciones en requerimientos

A continuación se muestran los Cambios en el Diagrama burn-up chart:

Ilustración : Diagrama Burn-up chart con modificaciones en requerimientos

Bibliografía

Cohn, M. (10 Septiembre 2019). Why the Fibonacci Sequence Works Well for Estimating? .
https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-e
stimating

Gibbons, S. (7 Julio 2019). Dot Voting: A Simple Decision-Making and Prioritizing Technique
in UX. https://www.nngroup.com/articles/dot-voting/

Martin, J.(16 Noviembre 2016). ¿Tienes un producto Kano?

https://www.cerem.es/blog/tienes-un-producto-kano

Shahin y col. Typology of Kano models: a critical review of literature and proposition of a
revised model. En: International Journal of Quality & Reliability Management 30.3 (2013),
págs. 341-358

Garzas, J. (17 Diciembre 2013). Gráficos Burn–down vs Burn-up para el seguimiento de un

Tema Métricas y estimaciones | 24

proyecto ágil. https://www.javiergarzas.com/

Álvarez García, A., de las Heras del Dedo, R., Lasa Gómez, C. (2012). Métodos Ágiles y
Scrum. Anaya Multimedia.

Tema Métricas y estimaciones | 25