-
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured / Scrum
Size matters?
This is a very old question, but in this blog, we only will answer that question from the project management point of view (disappointed people please go to another kind of blogs). This time we will see what are and what is the purpose of the famous User Stories and how they differ from traditional requirements in a project.
When I was a kid I spent a lot of time playing on the beach with my cousins, and in some of those games, I found myself digging, transporting and piling sand from one point to another (my tools were a shovel and a plastic bucket) after about 10 minutes my youngest cousin asked me how long it had taken me to gather all that sand, to which I replied: “about 30 laps”. After that, both my cousin and I assumed that with his own bucket he could double the amount of sand, doubled in another 30 laps. It wasn’t like that, it took a lot longer for my little cousin because we both failed to evaluate the capacity of his bucket and appreciating that Gabriel (my cousin) being very young (maybe 6 years old) he still had to strain to load a bucket of different size completely filled and finish in only 30 laps.
As simple and obvious as this anecdote may seem, the reality is surprising, since many work teams responsible for projects of all sizes continue to fall into this same error. They are not yet fully aware of their capacity or speed, nor are they clear about the difference between size and distance in a project, and therefore, they fail from the beginning in their estimates.
Not taking care of trying to measure the size of what you are going to do is an error, therefore the size does matter, and before measuring times and distances you should know the answer to questions like, what is the size of your bucket and shovel? How many buckets and shovels do you have? Are there enough people for each shovel and bucket?
What are the User Stories?
For ease, the concept is often oversimplified, saying that User Stories are the requirements of a system or a product, but they have serious differences with other common approaches such as use cases, IEEE 830 software requirements specifications, and design and interaction scenarios.
User stories are short, simple descriptions of a feature told from the perspective of the person who wants the new functionality, usually a user or customer of the product that they want to create. In general, they follow a simple template:
As <user type>, I want <some goal> so that <some reason>.
User stories are often written on chips or sticky notes, stored in a box and organized on walls, boards or tables to facilitate planning and discussion. As such, they strongly change the approach of writing about characteristics, to discussing them. In fact, these discussions are more important than any text that is written.
This is a simple definition about what a User Story is, but believe me, there is much more behind, writing good User Stories can be a challenge, and to create good stories you have to understand more about their purpose.
Assign Value (points) to User Stories
Eventually, when I became involved in project management and later Agile, I discovered that one way to estimate the size of what is needed is to use the User Stories. To explain what they are I will continue using the analogies.
When was the last time you went to a restaurant and ordered a soup or a drink in milliliters? … That’s right, we usually don’t do that, we usually order a soup or a drink with a relative measure like “small, medium or large”. User stories are also relative, they are used to express size, they don’t have a standardized value, but the values must be relative to each other, that is, a User Story that has value 2 is twice the size of one User Story that it’s worth 1.
To assign values or points to different sizes there are those who use shirt sizes, dog breeds, Fibonacci values (my favorite values) or other representations, no matter what you prefer, you should eventually use relative values. Take the following table as an example, with a possible assignment of points:
Tamaño Camisa Puntos XS 1 S 2 M 3 L 5 XL 8 XLL 12 In an Agile project, it is not uncommon to start an iteration with requirements that are NOT fully specified, the details will be discovered later during the iteration. However, we must associate an estimate with each story that we can see at the moment, even those that are not completely defined.
And where are the details?
Those used to the detail added in advance into traditional requirements will immediately come up with this question. The detail can be added to User Stories in two ways:
- Dividing a User Story into multiple User Stories and smaller ones.
- Adding “conditions of satisfaction”.
When a relatively large story is divided into Agile and multiple User Stories, it’s normal to assume that details have been added. After all, more has been written.
Conditions of Satisfaction are simply high-level acceptance tests that must be met after the User Story is completed. Consider the following as another example of an Agile User Story:
As a marketing director, I want to select a period of time so that I can review the past performance of advertising campaigns in that period.
The detail could be added to this User Story example by adding the following satisfaction conditions:
- Make sure it works with the data of the main retailers: Oxxo, Seven Eleven, Extra.
- It must support the data for the last three years.
- The periods are chosen in intervals of months (not days, nor weeks).
Who writes User Stories?
Anyone can write User Stories. However, it is the responsibility of the product owner to ensure that there is an accumulated backlog of Agile User Story products, but that does not necessarily mean that the owner of the product is the one who writes them. In the course of a good Agile project, you must have examples of User Story written by each member of the team.
Also, keep in mind that who writes a User Story is much less important than who is involved in the discussions of it.
When are User Stories written?
The User Stories are written throughout an Agile project. Overall, a story writing workshop is held near the start of the Agile project, each release and/or at the beginning of each iteration (I personally take some of the first options, depending on the length of the project, and I only do refinement in each iteration). Everyone on the team participates with the goal of creating an “order list” or Product Backlog that fully describes the functionality that will be added during the course of the project, or in a release cycle of three to six months.
Some of these Agile User Stories will undoubtedly be Epics (are not called Epics because they are dramatic…well sometimes 😄). Epics are very large stories that by their size will later decompose into smaller stories that fit more easily into a single iteration. In addition, new stories can be written and added to the “order list” of the product at any time and by anyone.
Velocity
I will not delve too much into this topic because it gives to write another post dedicated entirely to it, but to understand how estimation can work with Story Points that we assign in the table we showed above, it’s necessary to introduce a new concept: Velocity. Velocity is a measure of a team’s progress rate. It’s calculated by adding the number of Story Points assigned to each User Story that the team completed during the iteration.
If the team completes three stories, each estimated at five story points, its velocity is fifteen. If the team completes two stories of five points, its velocity is ten.
If a team completed ten points of work the last iteration, our best calculation is that this iteration will complete ten points. Because the story points are estimates of relative size, this will be true whether they work on two five-point stories or five two-point stories.
As can you see, in order to make estimations, and after knowing the sizes It’s very important to calculate an estimate for the end of the project, or for a release (the distance).
Do User Stories replace a requirements document?
Agile projects, especially Scrum projects, use a product backlog, which is a prioritized list of functionalities that will be developed in a product or service. Although product backlog items may be what the team wants, User Stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be considered as a replacement for the requirements document of a traditional project and perhaps even a WBS, it’s important to remember that the written part of an Agile User Story (“As a user, I want …” ) is incomplete until the discussions about that story take place.
It’s often better to think of the written part as an indicator of the actual requirement. User Stories can point to a diagram that represents a workflow, a spreadsheet that shows how to perform a calculation or any other artifact that the Product Owner or team wants.
Until here I leave the User Stories topic, for now, let me know if you want to know more 😉.
Links of interest:
Without users (User Proxies)
The Agile Team Approach
What Scrum Master Certification to Choose?These are some recommended books to learn more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Destacadas / Featured¿El tamaño importa?
Esta es una pregunta muy vieja, pero en este blog solo contestaremos a esa interrogante desde el punto de vista de la administración de proyectos (descepcionad@s dirigirse a blogs de otro tipo). En esta ocasión veremos que son y cuál es el propósito de las famosas historias de usario o user stories y en que se diferencían con los requerimientos tradicionales en un proyecto.
Cuando era niño pasé mucho tiempo jugando en la playa con mis primas y primos, y en algunos de esos juegos, me encontré escarbando, transportando y apilando arena de un punto a otro (mis herramientas eran una pala y una cubeta de plástico) después de unos 10 minutos mi primo más pequeño me preguntó cuanto me había tardado en juntar toda esa arena, a lo cual contesté: “como unas 30 vueltas”. Después de eso tanto mi primo y como yo supusimos que con su propia cubeta podría duplicar la cantidad de arena en otras 30 vueltas. No fue así, mi primo pequeño todavía, se tardó bastante más debido a ambos fallamos en evaluar la capacidad de su cubeta y en apreciar que Gabriel (mi primo) al ser muy pequeñito (quizá 6 años) aún tenía que esforzarse para cargar una cubeta de diferente tamaño completamente llena y terminar en sólo 30 vueltas.
Por simple y obvia que parezca esta anécdota, la realidad sorprende, ya que muchos equipos de trabajo encargados de proyectos de todos tamaños siguen cayendo en este mismo error. Aún no están completamente al tanto de su capacidad o su velocidad, tampoco tienen claro la diferencia entre tamaño y distancia en un proyecto, y por lo tanto, fallan desde el principio en sus estimaciones.
No ocuparse de tratar de medir el tamaño de lo que se va a hacer es un error, por lo tanto el tamaño, SÍ importa, y antes de medir tiempos y distancias usted debe saber la respuesta a preguntas como ¿cuál es el tamaño de su cubeta y su pala? ¿cuántas cubetas y palas tiene? ¿existe la cantidad de personas suficiente para cada pala y cubeta?
¿Que son las historias de usuario?
Por facilidad muchas veces se sobre simplifica, diciendo que las historias de usuario o user stories son los requerimientos de un sistema o un producto, pero tienen serias diferencias con otras aproximaciones comunes como son los casos de uso, especificaciones de requisitos de software IEEE 830 y escenarios de diseño e interacción.
Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva funcionalidad, generalmente un usuario o cliente del producto que se desea crear. Por lo general, siguen una plantilla simple:
Como <tipo de usuario>, quiero <algún objetivo> para que <algún motivo>.
Las historias de usuario a menudo se escriben en fichas o notas adhesivas, se almacenan en una caja y se organizan en paredes, pizarrones o mesas para facilitar la planificación y el debate. Como tales, cambian fuertemente el enfoque de escribir sobre las características, a discutirlas. De hecho, estas discusiones son más importantes que cualquier texto que se escriba.
Esta es una definición simple de que es una historia de usuario, pero créame, hay mucho más detrás, redactar buenas historias de usuario puede ser un reto, y para lograr hacer buenas historias hay que entender más acerca de su propósito.
Asigna Valor (puntos) a las historias de usuario
Eventualmente, cuando me involucré en la gestión de proyectos y más tarde Agile, descubrí que una manera de estimar el tamaño de lo que se necesita es utilizar las historias de usuario. Para explicar lo que son seguiré echando mano de las analogías.
¿Cuándo fue la última vez que fue a un restaurante y pidió una sopa o una bebida en mililitros?…..así es, normalmente no hacemos eso, solemos pedir una sopa o una bebida con una medida relativa como “chica, mediana o grande”. Las historias de usuario son relativas también, se usan para expresar tamaño, no cuentan con un valor estandarizado, pero los valores deben ser relativos uno de otro, es decir, una historia de usuario que tenga valor 2 es del doble de tamaña de una que vale 1.
Para asignar valores o puntos a diferentes tamaños hay quienes usan tallas de camisa, razas de perros, valores Fibonacci (mis valores favoritos) u otras representaciones, no importa que prefiera, eventualmente debe usar valores relativos. Tome como ejemplo la siguiente tabla, con una posible asignación de puntos:
Tamaño Camisa Puntos XS 1 S 2 M 3 L 5 XL 8 XLL 12 En un proyecto Agile no es raro comenzar una iteración con requisitos que NO son completamente especificados, los detalles se descubrirán más tarde durante la iteración. Sin embargo, debemos asociar un estimado con cada historia que podamos visualizar en el momento, incluso a aquellas que no están completamente definidas.
¿Y en dónde están los detalles?
Aquellos acostumbrado a el detalle que se agrega de antemano a los requerimientos tradicionales, de inmediato les surgirá esta pregunta. El detalle se puede agregar a las historias de usuario de dos maneras:
- Dividiendo una historia de usuario en múltiples historias de usuarios y más pequeñas.
- Agregando “condiciones de satisfacción”.
Cuando una historia relativamente grande se divide en historias de usuarios ágiles y múltiples, es natural suponer que se han agregado detalles. Después de todo, se ha escrito más.
Las condiciones de satisfacción son simplemente pruebas de aceptación de alto nivel que deberán cumplirse después de que se complete la historia del usuario. Considere lo siguiente como otro ejemplo de historia de usuario ágil:
Como director de marketing, quiero seleccionar un periodo de tiempo para que yo pueda revisar el rendimiento pasado de campañas publicitarias en ese periodo.
El detalle podría agregarse a este ejemplo de historia de usuario al agregar las siguientes condiciones de satisfacción:
- Asegúrese de que funcione con los datos de los principales minoristas: Oxxo, Seven Eleven, Extra.
- Debe soportar los datos de los últimos tres años.
- Los periodos se eligen en intervalos de meses (no días, ni semanas).
¿Quién escribe historias de usuarios?
Cualquiera puede escribir historias de usuario. Sin embargo, es responsabilidad del propietario del producto o product owner asegurarse de que exista un retraso acumulado de productos de historias de usuario ágiles, pero eso no significa necesariamente que el propietario del producto es quien los escribe. En el transcurso de un buen proyecto Agile, debe contar con ejemplos de historia de usuario escritos por cada miembro del equipo.
Además, tenga en cuenta que quién escribe una historia de usuario es mucho menos importante que quién está involucrado en las discusiones de la misma.
¿Cuándo se escriben las historias de los usuarios?
Las historias de usuario se escriben a lo largo de un proyecto ágil. Por lo general, se lleva a cabo un taller de redacción de historias cerca del inicio del proyecto ágil, de cada relese y/o al inicio de cada iteración (personalmente tomo algunas de las primeras opciones, según la longitud del proyecto, y solo hago grooming en cada iteración). Todos en el equipo participan con el objetivo de crear una “lista de pedidos” o Product Backlog que describa por completo la funcionalidad que se agregará durante el transcurso del proyecto o en un ciclo de lanzamiento o release de tres a seis meses.
Algunas de estas historias de usuarios ágiles serán, sin duda, épicas o epics (no se llaman épicas por que se dramáticas 😄). Las épicas son historias muy grandes que por su tamaño se descompondrán más tarde en historias más pequeñas que quepan más fácilmente en una sola iteración. Además, las historias nuevas se pueden escribir y agregar a la “lista de pedidos” del producto en cualquier momento y por cualquier persona.
Velocidad (Velocity)
No profundizaré tanto en este tema porque da para escribir otra entrada dedicada por completo a ello, pero para comprender cómo puede funcionar la estimación con puntos de historia que asignamos en la tabla que mostramos anteriormente, es necesario introducir un nuevo concepto: Velocidad o Velocity. La velocidad es una medida de la tasa de progreso de un equipo. Se calcula sumando la cantidad de puntos de historia asignados a cada historia de usuario que el equipo completó durante la iteración.
Si el equipo completa tres historias, cada una estimada en cinco puntos de historia, su velocidad es de quince. Si el equipo completa dos historias de cinco puntos, su velocidad es diez.
Si un equipo completó diez puntos de trabajo la última iteración, nuestro mejor cálculo es que completarán diez puntos esta iteración. Debido a que los puntos de la historia son estimaciones del tamaño relativo, esto será cierto ya sea que trabajen en dos historias de cinco puntos o cinco historias de dos puntos.
Cómo puede ver esto es muy importante para hacer una estimacion y despúes de conocer el tamaño, para después proceder a calcular una estimación para el final del proyecto o de un release (la distancia).
¿Las historias de usuario reemplazan un documento de requisitos?
Los proyectos ágiles, especialmente los de Scrum, usan un product backlog, que es una lista priorizada de las funcionalidades que se desarrollarán en un producto o servicio. Aunque los product backlog items pueden ser lo que el equipo desee, las historias de usuario han surgido como la mejor y más popular forma de product backlog items.
Si bien un product backlog, puede considerarse como un reemplazo de el documento de requisitos de un proyecto tradicional e incluso quizá de un WBS, es importante recordar que la parte escrita de una historia de usuario ágil (“Como usuario, quiero …”) está incompleta hasta que las discusiones sobre esa historia tienen lugar.
A menudo es mejor pensar en la parte escrita como un indicador del requisito real. Las historias de usuario pueden apuntar a un diagrama que representa un flujo de trabajo, una hoja de cálculo que muestra cómo realizar un cálculo o cualquier otro artefacto que el propietario del producto o equipo deseen.
Hasta aquí dejo las user stories, déjeme saber si quiere saber más 😉.
Enlaces de interés:
El Enfoque Agile De La Planeacion
Planeación, Cono de Incertidumbre y Estimaciones en IT
Introduction to User StoriesEstos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
