Ir al contenido principal

Como implementar Scrum en 10 pasos fáciles - Paso #2: Como estimar tu pila del producto



Continuamos con la serie "Como implementar Scrum en 10 pasos fáciles", escrita originalmente por Kelly Waters. Estamos con el paso #2.

El artículo original es: How To Estimate Your Product Backlog

 Les dejo con la traducción:



Como estimar tu pila del producto.

En el paso 1 describí como poner en orden tu pila del producto.

Si has completado el paso 1 ¡Felicidades! Por que es el paso mas grande. Y el fundamento para todo lo que sigue. Implementes o no, Scrum.

Si no has completado el paso 1, no vallas mas allá hasta que lo tengas.

Así que aquí esta el paso #2: Como estimar tu Pila del Producto

Estimación de alto nivel

Necesitas proveer de una estimación inicial de alto nivel. Para tener una idea del tamaño de los items de tu Pila del Producto.

Esto es útil por que ayuda a informar la decisión sobre prioridades. Y si es probable o no que las características valgan la pena. Y desde un punto de vista de gestión, da una perspectiva de cuan grade debe ser el equipo.

Pero como aún, no sabes mucho sobre los items en la Pila. No sabes que características están destinadas a hacerse. No sabes que tareas son necesarias para completarlas. Y no sabes  en realidad como las implementarás.

Así que tienes que hacer un estimado indicativo de muy alto nivel, desde arriba hacia abajo. De hecho es una suposición, no un estimado realmente.

Cuantas veces has oído a alguien decir, "no te preocupes, no te mantendré en esto, solo necesito una idea aproximada". Y por supuesto que sí te mantienen en ello. Por supuesto que lo hacen.


Estima la Pila del Producto en Puntos.

La respuesta: Estimar la pila del producto en puntos. No en unidades de tiempo.

Repite: Estimar la pila del producto en puntos, no en unidades de tiempo.

No, no me he vuelto loco. Se que suena un poco loco. Pero te voy a pedir que confíes en mí; tiene sus razones, algunas de las cuales se vuelven claras luego en esta serie.

Mientras tanto, te pediré que aceptes que los equipos de desarrollo están mas dispuestos a dar estimaciones de "tamaño", sin dar un estimado de tiempo al cual ellos deban estar apegados y sin tener todos los detalles.

 Así que no le estamos preguntando al equipo "¿cuanto tiempo tomará?". Estamos preguntando "¿qué tan grande es?"

También te pido que aceptes que los Propietarios del Producto están mas inclinados a tomar esto como una suposición - lo cual es lo deseado - y no como un compromiso prematuro.

Ahora bien, me doy cuenta que los puntos pueden ser vistos como inútiles para un Propietario del Producto en términos de hacer un modelo de negocio para el financiamiento. Ciertamente hasta un equipo tiene un historial y sabemos aproximadamente cuantos puntos ellos tienden a realizar en una iteración. Pero regresaré a eso luego. Ciertamente, aun esto es útil para la priorización y para obtener el tamaño relativo de una característica para un Propietario del Producto.

Usar un Sistema de Puntos

¿Qué escala usarías para tu sistema de puntuación?

Personalmente me gustan los números de Fibonacci.

Para las personas inteligentes, sigan el enlace de arriba para entender lo que son los números de Fibonacci. Para personas mas simples como yo :-) son básicamente una secuencia de números que alguna gente antigua y muy inteligente (generalmente italianos, como de costumbre) han elaborado, tienen una ligeramente espeluznante, pero gran significativo científico. Y este significativo se relaciona con la física y las leyes de distribución.

Mas sobre Fibonacci está realmente mas allá del alcance de este artículo, pero ellos son un conjunto de números científicamente significativos, donde cada número es la suma de los anteriores 2. Ellos son:

1,2,3,5,8,1.,21,34,55,89,144,233,377,610,987...

 Por simplicidad, cuando estés usando estos números para indicar tamaño, sugiero que uses el rango 1-21. Ciertamente para corrección de errores y mejoras en los productos en el ciclo BAU(Business-As-Usual [negocios usuales]), debería ser un rango suficiente. Tal vez reserva el 987 para esas tantas peticiones que te piden y a la luna y regresar en un cartón de helado :-)

La clave aquí es la productividad.

Un ítem de la pila describe una característica. Tal vez, por ejemplo, es un reporte. Has hechos reportes similares antes, pero este tiene una complejidad en los datos subyacentes, así que decides darle a este un 3.

El siguiente en la pila es otro reporte. Tu estimas este de manera relativa al otro. Es mas grande o mas pequeño. Claramente 21 es mucho mas grande. 2 es un poco mas pequeño. Y continuas.

Para asegurar que la escala funciona para ti, sugiero que inicies tomando el que piensas que es el ítem mas pequeño en la pila. Asignale 1. Luego encuentra el que piensas es el mas grande en la pila. Asignale 21.

Ahora tienes tus marcadores, estima la pila, trabajando desde arriba, usando los números de Fibonacci.

Cuando vayas hacia abajo en la pila, llegaras a un punto donde los items son realmente muy confusos. Y de muy baja prioridad. De hecho no estás seguro si llegaras hasta ellos en tu tiempo de vida. Por favor no sientas que tienes que estimar la pila completa. Estima la suficiente cantidad de items que puedas desarrollar en un futuro cercano. Recuerda que ya está en orden de prioridad. Así que asegurate de trabajar desde arriba.

Estima como equipo

Estima tu pila como un equipo. Hay toda una filosofía sobre la "Sabiduría de los grupos". Dos mentes son mejores que una, etc, etc. Si hay grandes diferencias, usa esto como un punto de discusión para entender por que. ¿Vio una persona problemas y complicaciones que otra no pudo ver? ¿Vió una persona un bonito y simple enfoque que los demás no pudieron ver?

Considera usar Planeación por Poker. Esta es una técnica divertida que asegura que las personas no se influencian entre si. Cada miembro del equipo anota su estimado en una tarjeta, y todos muestran sus respuestas a la vez. Esto ayuda a asegurar que los miembros con menos experiencia en el equipo estén igualmente comprometidos y no sobre-influenciados por miembros mas experimentados. Esto ayuda también a estimadores menos experimentados a aprender de otros.

A partir de este ejercicio, negocia el tamaño de cada ítem de la pila como equipo.

Revisa prioridades

Una vez que has estimado tu pila - o lo suficiente de ella - pide al Propietario del Producto que le de un vistazo nuevamente a las prioridades. Tal vez ahora ellos puedan ver el tamaño relativo de las características que ellos han pedido, podrían cambiar su visión de las prioridades. "Wow, si eso es un 21, quiero entonces tener esto otro primero", o "si eso es simplemente un 2, dejemoslo para la próxima iteración". Si alguna prioridad ha cambiado, simplemente mueve el la posición del ítem en el orden de la pila.

Adherencia al programa

Resiste el impulso de adaptar este paso. El libro de Ken Schwaber, "Agile Software Development with Scrum", el cual es altamente recomendado por cierto, dice esto: Si tu no eres aun un experto en el contenido de la materia (ejem. Scrum) no intentes adaptarlo. Scrum es un proceso adaptativo. Pero no estás en posición de adaptarlo hasta que lo conozcas bien y lo hayas experimentado en operación.

Estimar tu pila del producto usando puntos es una de las cosas que te animo a no adaptar hasta que lo hayas probado en un período de varios Sprints de manera que puedas ver los efectos.

Kelly


Serie completa:
#2: Cómo estimar tu pila del producto

Entradas populares de este blog

Enumerar filas en una consulta con MySQL

Supongamos que tenemos tablas con la estructura siguiente:
documentos (iddocumento, nombre_documento, url_original, idtipo_documento, idproyecto) proyectos (idproyecto, nombre_proyecto, longitud, unidad_medida) tipo_documentos (idtipo_documento, descripcion_tipo_documento) Tenemos necesidad de hacer una consulta como la siguiente: "Enumerar todos los documentos en la base de datos agrupados por proyecto"

Parece fácil, excepto por el término "enumerar", aquí tienes un truquito para que logres enumerar tus consultas:
SELECT (@rownum:=@rownum+1) AS rownum, nombre_documento, descripcion_tipo_documento, nombre_proyecto FROM (SELECT @rownum:=0) r, documentos AS d INNER JOIN proyectos AS p ON d.idproyecto = p.idproyecto INNER JOIN tipo_documentos AS td ON d.idtipo_documento = td.idtipo_documentoPero que tal si te piden que enumeres los proyectos con sus correspondientes documentos?. Teniendo lo anterior es un poco mas sencillo
SELECT IF(@fila=proyectos.idproyecto, @rownum:…

Expresiones Regulares y pruebas en javascript

¿Qué es una expresión regular?
Una expresión regular es una cadena que contiene una combinación de caracteres normales y metacaracteres o metasecuencias especiales. Los caracteres normales coinciden por ellos mismos. Los metacaracteres y metasecuencias son caracteres o secuencias de caracteres que representan ideas como cantidad, posiciones o tipos de caracteres.
Regular Expression Pocket Reference 2nd Ed - Tony Stubblebine - O'Reilly

¿Para qué son útiles las expresiones regulares?
Las expresiones son especialmente útiles para validar información, por ejemplo en formularios de ingreso de datos. Por ejemplo para validar que se ingresó un número de teléfono, puedes usar la siguiente expresión regular.

/^([\+][0-9]{1,3}[ \.\-])?([\(]{1}[0-9]{2,6}[\)])?([0-9 \.\-\/]{3,20})?$/

Parecieran símbolos al azar, pero nada mas lejos de la realidad. Te muestro una tabla básica con los elementos usados para crear expresiones regulares.

Carácter Texto buscado ^Principio de entrada o línea.$Fin de e…

Como implementar SCRUM en 10 pasos fáciles - Paso #1: Ordena tu "Pila del Producto"

Esta es la continuación de la serie: Como implementar SCRUM en 10 pasos fáciles. Creación de Kelly Waters y traducida con la autorización correspondiente por su servidor.


La entrada original de este artículo es: Get your backlog in order

Ordena tu "Pila del Producto"
¿Así que quieres implementar Scrum?
¿Y te gusta la idea de hacerlo fácilmente?
Entonces escucha. Este es el paso 1 en mi serie: ¿Cómo implementar Scrum en 10 pasos fáciles.
Este no es solo el primer paso. Es el paso más importante.
A menos que puedas llevar a cabo este paso, no sigas. No lo saltes. Te prometo que te arrepentirás si lo haces. Incluso si no continuas, es probable que este paso te beneficie, a tu equipo y a tu organización.
Así que aquí está.
Primero, ¿dónde deberíamos empezar?
Alineación con el negocio
Primero, antes de nada, debes alinear tu equipo de desarrollo con el negocio.
Si eres parte de una unidad de negocio, eso puede ser natural y directo. Si estas en una organización central de desarrol…