Size Matters, User Stories.

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: