E-Historia de Usuario y Estimacion I

7/29/2019 E-Historia de Usuario y Estimacion I

1/28

HISTORIA DE

USUARIO I


2/28

Ordenando el backlog (Priorizacin)

El backlog debe ordenarse por valor de negocio.

Como mnimo necesitaremos el juicio subjetivo del Product Owner para

poder valorar una funcionalidad frente a las otras.

El backlog debe contener como mnimo la suficiente cantidad de tems que

permitan planificar el primer sprint.

Comnmente el backlog contiene todos los tems que conforman el prximorelease del producto.


3/28

Hablemos de tcnicas simples como el planning poker o la estimacin por afinidad.

El planning poker funciona en parte dado que tiene una slida base terica, pero sobre

todo porque quienes estiman son aquellos que en definitiva llevarn a cabo el trabajo.

El planning poker es rpido. Un equipo con prctica estimar en promedio un tem

cada 3 minutos.

El planning poker es preciso. Las estimaciones obtenidas utilizando planning poker son

tan buenas como las obtenidas usando mtodos tradicionales.

Estimando el Backlog


4/28

La estimacin por afinidad es an ms rpida que el planning poker. Es genial paraequipos que tienen un backlog completo para estimar y el tiempo es ms importante

que una gran precisin y distribucin del conocimiento.

Estimando el Backlog


5/28

Algunas aclaraciones:

Estimamos los tems de forma relativa entre ellos.

Por qu?

Resulta fcil acordar que esta historia tiene el doble de complejidad que esta aunque no

sepamos an cunto tiempo tomar implementarlas.

Estimamos los tems usando unidades de complejidad en vez de unidades de tiempo.

Por qu?

Esto nos escuda frente a la necesidad de ajustar las estimaciones dependiendo de quin

realiza el trabajo o cuando las habilidad y capacidad del equipo cambian con el correr del

tiempo.


6/28

Algunas aclaraciones:

Usamos una escala no linear porque la diferencia entre 1 y 2 es obviamente

ms significativa que la que hay entre 20 y 21.

En general se usa la escala basada en la serie de Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40 and 100.

Luego se define el rango que va del 1 al 8 (o incluso al 13) como los posibles

tamaos de los tems que un equipo puede desarrollar durante un sprint.

Los nmeros ms grandes se dejan para historias ms grandes (picas), que

debern ser subdivididas en pequeas historias antes de ingresar a un sprint.


7/28

Historia de usuarios


8/28


9/28

Caractersticas


10/28

PBI= tarjeta + gente hablando + ejemplo

(PBI= Product Backlog Item= user story)


11/28


12/28

Criterio de Aceptacion

Las condiciones de satisfaccin de los objetivos suelen ponerse en forma de pruebas

de aceptacin que se realizarn, indicando cmo debe comportarse el sistema

(o BDD, Behaviour Driven Development) con el formato "Dado aaa, cuando se

produzca bbb, entonces ccc", donde aaa es la situacin en la que se encuentra el

sistema, bbb es un evento que lo har cambiar y ccc es el resultado. Esta tcnica

permite evitar la aparicin de errores por malos entendidos y evitar retrabajar

(siguiendo los principios Lean). Por ello es recomendable no empezar a desarrollar

en una iteracin sin antes haber escrito los casos de prueba, especialmente por que

es ms barato escribir texto y pensar en cmo desambiguar los requisitos quearreglar errores importantes debido a su mal entendimiento.


13/28


14/28

Links con ejemplos:

http://www.mountaingoatsoftware.com/scrum/product-backlog-example/
http://www.mountaingoatsoftware.com/scrum/product-backlog-example/http://www.mountaingoatsoftware.com/scrum/product-backlog-example/http://www.mountaingoatsoftware.com/scrum/product-backlog-example/http://www.mountaingoatsoftware.com/scrum/product-backlog-example/http://www.mountaingoatsoftware.com/scrum/product-backlog-example/http://www.mountaingoatsoftware.com/scrum/product-backlog-example/


15/28

Definiendo roles de usuarios

Tener en cuenta:


16/28

Definiendo roles de usuarios

Ejemplo:


17/28

TIPS

No es una buena idea comparar las estimaciones entre equipos. Las mismas

son intiles, a menos que stos se encuentren trabajando sobre el mismo

backlog.


18/28

Planificacin del release

Una vez que hemos ordenado y estimados el backlog, el siguiente paso es crear la

primer versin del plan de release.

Para ello necesitamos una estimacin de la velocidad de nuestro equipo. Sin

embargo, no hemos hecho ningn trabajo an, por lo que utilizaremos una tcnica

muy simple denominadaplanificacin basada en el compromiso (commitment

based planning).

Primero, por supuesto, debemos conocer el tamao que tendr el equipo durante

el sprintes importante saber si algn miembro estar ausente.

Segundo, debemos elegir una longitud de sprintusualmente 2 semanas para un

equipo nuevo.

Y por ltimo es necesario crear una definicin de HECHO para el equipoqu

significa cuando el equipo dice que ha terminado con una historia.


19/28

A continuacin el ScrumMaster toma el primer tem del backlog y pregunta al equipo:

Pueden completar este tem durante el sprint?.

Esta dinmica contina hasta que el equipo siente que ya no puede comprometerse a

ms tems.

Sumando los tamaos del backlog comprometido ya tenemos una estimacin inicial de

velocidad.

Este valor de velocidad es utilizado para dividir y ubicar los tems restantes (al menos

aquellos que han sido estimados) en los sprints subsiguientes.

Esta lista de tems asociados a sprints es la versin inicial de nuestro plan de release.

Es precisa la estimacin?

Tal vez no, pero es seguramente ms creble que cualquier otra a la que

podra haber llegado un gestor de proyecto por si solo en una etapa tan temprana del

proyecto.

Una vez que comenzamos el trabajo, al finalizar un sprint tras otro, podremos graficar

nuestra verdadera velocidad y utilizar este dato para predecir el

ritmo futuro de entregas. Por ello decimos que plan de release es un ente vivo que se

hace ms y ms confiable en la medida en la que progresamos.


20/28

Luego de estimar los tems del backlog podra suceder que necesitamos reordenar

algunos de ellos. Deberemos tomar los siguientes factores en cuenta, adems del valor

de negocio:

Tamao: naturalmente elegiremos implementar una historia simple (pequea)

antes que una compleja (grande) si poseen un valor de negocio similar.

Aprendizaje: podremos elegir implementar una historia antes si el equipo considera

que desarrollarla ayudar a que ste comprenda mejor el dominio de negocios o una

nueva tecnologa.

Riesgo: tal vez elijamos implementar una historia de manera temprana porque de esta

forma estaremos mitigando un riesgo que hemos identificado. Ejemplos obvios sontems que nos ayudarn a establecer lmites de rendimiento y escalabilidad.

Nunca debemos olvidar que el Product Owner siempre tendr la ltima palabra en lo

que se refiere al ordenamiento del backlog.

Reordenando el Backlog


21/28

En prcticamente todos los casos es suficiente, y generalmente preferible, crear y

mantener un Product Backlog compuesto exclusivamente de un conjunto de historias

de usuario escritas sobre fichas pequeas (ejemplo: de 150 x 100 mm )

Ron Jeffries [Jeffries 2005] acu la frase Tarjeta, Confirmacin, Conversacin (Card,

Confirmation, Conversation - las 3Cs) para describir cmo debe trabajarse con las historias.

Las historias suelen ser escritas desde la perspectiva de un usuario del producto.


22/28

EJEMPLO

HISTORIA DE USUARIO


23/28

Procesos de negocio del proyecto

En la siguiente slide seanaliza este proceso


24/28

Funcionalidades


25/28

Ejemplo de estructura del Release 3

En este Release se

entregan funcionalidades

de 2 procesos

Y se comprometen a entregar 5historias de usuarios (ver

siguiente slide)

1

5

4

3

2


26/28

Historias de usuarios del Release 3

1

5

4

3

2


27/28

Ejemplo de etimacion del Release 1


28/28

Ejemplo de duracion y fechas del Release 1

E-Historia de Usuario y Estimacion I

Documents