On story points, estimations and user story splitting (Part I)

I decided to write this article because I’ve seen several times that young developers that join companies tend to misunderstand or struggle with the concepts of story points and estimations, and also because I’ve met product teams that in my opinion do not invest the necessary time grooming their backlogs and splitting user stories.

I am well aware that there has been an ongoing debate (#noestimates) in the community since 2012 that questions the need of estimating in the agile teams — I will avoid that debate and leave it to the reader, but I can state that having proper estimates is something that helps the business development departments a lot, and since a significant amount of the companies use them, I think that this piece may be quite helpful. The concept of story points is directly related to the way we should prepare a backlog and roadmaps. From a Product Owner perspective it is as important to know what do story points imply for our responsibilities rather as exactly knowing what story points are.

This article is divided in 3 parts.

I will first try to explain what story points are and why are they used in many teams and companies. I will introduce no novelty here, but I will try to provide some practical examples on the concept to detail it better.

In the second part, having the story point introduction as our context, I will try to explain the motivation and analyze the reasons to explain why should a team split user stories. Any agile team should be completely aware of the reasoning behind this practice. Finally, the last section will be much more practical, as I try to present the most common patterns that can be looked for when splitting user stories and provide some real examples of user story splitting.

The text ahead is long, consider yourself warned but I think it made sense to start from the most basic concepts and revisit them in a journey through a process that is done time after time on a weekly basis in our companies.

I will try to provide practical examples and scenarios so you can relate the concepts I’m trying to present with situations you may have encountered in your own company.

I hope you find it interesting and it helps you as well — let’s go

Part One – User Story Points

Let’s talk about story points

Story points are an indicative measure that the agile teams use to estimate the time that will take to implement a task. And I’m completely aware of the use of “time” in that sentence has room for discussion, but at the end of the day, the Product Owner translates an amount of story points to sprints, that is weeks, that is time

The first question would be, if the story points result in time, why didn’t we use time to estimate tasks in the first place? Well, some teams do. Some don’t. From a very simplified perspective, the main reason not to use hours or days is because the time units are absolute and the development teams are sometimes not comfortable providing an absolute estimation of tasks that may not be completed in that time frame because some details are yet to be solved at the moment of providing this estimation.

So instead of hours, a lot of development teams prefer using story points.

So what is a story point exactly?

In some literature the story point is said to measure difficulty or complexity of a user story – I disagree with that one, it is correct yet incomplete. Some other (most) texts define it as a measure of effort , which I tend to like better. Let’s analyze what effort means and ask ourselves how different can effort be?

Let’s try to put ourselves in the skin of a development team and imagine that we have to estimate the effort that 3 (super simplified) user stories would take to implement:

• As a user I want to see my website in French
• As a user I want to blur an image so that it looks cooler
• As a user I want to add an external 3rd party SMS payment gateway API to my payment methods

*First case: *

“As a user I want to see my website in French”

Assume we have a website with 100+ views, and all the strings we display are literal strings hard coded in the source. The complexity of this task is close to none, we only have to parse all the documents of the source code searching for string literals, replace it with a tag, build up some kind of localization system (JSON file or whatever) and that’s it.

But we have 100+ views.

This user story is tedious. It is not hard, it is not complex — but it will take a lot of time and is boring as hell. The effort that this can take is significant. I bet that no team would estimate that user story with a small value of story points, because even the less experienced development team knows that it may take a lot of time to complete.

*Second case: *

_“As a user I want to blur an image so that it looks cooler” _

Again, let’s make some assumptions. We have a team that is not familiar with image processing and will have to research many things.

Some questions that may arise:

• What does blur mean?
• Is there a library that can help me with that operation?
• Is there a way to use my internal data structures holding images with these libraries?
• Does the library work with my current set of dependencies?
• Can I handle the result?
• Will it be ok performance wise? etc

Blurring an image is an operation that takes one or two lines of code in most of the cases, and 20-30 if you have to code it yourself. It is not long. The problem here is to know what is to be coded, some teams may be completely uncertain about how much effort will this user story take.

A team that is not familiar with image processing techniques will probably estimate this task with a significant value or maybe even ask to timebox a spike first to know how to develop the task at hand.

*Third case: *

“As a user I want to add an external 3rd party SMS payment gateway API to my payment methods”

The final one. What we assume here is that we have a working product with a web version and Android and iOS version. We are given the task to integrate with another payment system that will help us monetize better in a market where we are struggling.

For the team it is a known task, we have integrated payment gateways before, but we’re also aware that we have to manage properly a lot of things (user feedback, edge cases, etc.), there is a degree of knowledge we still do not have if we’re not familiar with the API to integrate and we also know that it consists not only of implementing the integration from scratch, but to make it work with the system that is already in place.

Most of the teams would classify this feature as complex — it is not a problem of uncertainty, since it is a task feasible for the team, but we have to take many things into account (error management, edge cases, the integration itself) and adding a new payment method is not something to be taken lightly. On top of that, every existing part of the system has to keep running smoothly.

I hope my examples have been clear enough to depict that that sometimes it is difficult to estimate a task in an absolute time value and especially that an estimation can have different axis to take into account.

In the examples provided most of development teams would provide significant estimations to the tasks above, but for different reasons. A measure of effort is gathering 3 different concepts:

• Tediousness
• Complexity
• Uncertainty

That is to say that story points, a lineal value, is representing a three dimensional value. But that also means that we are not seeing directly these 3 factors.

It is something that a Product Owner should always keep in mind, and as a matter of fact, it is: when the team estimates – as I will elaborate on the following sections.

Let’s talk about estimations and velocity

Nice, that we know what story points are and the three concepts that hide behind the number. But how do they work in a practical environment?

We use story points to avoid estimating absolutely, but at the same time this raises another question, how much time equals a story point?

This is a key question that is critical for any product team in order to prepare roadmaps and forecast releases. Unfortunately, there is not a rule of thumb to solve that question as it depends on the team and project at hand.

But don’t worry, we don’t need one as you will see:

*Practical example 1: *

We have two development teams, Team A and Team B. Let’s assume that both of them are equally skilled, motivated and experienced. BUT the developers of Team A are rather optimistic and the members of Team B are mostly pessimistic.

Let’s imagine we present a scope of work to be estimated to both teams, and ask them to estimate the effort that would take to complete the list of tasks in story points. It will probably result in two different estimations, for instance:

• Team A : 18 story points
• Team B : 30 story points

Let’s remember, same skills, same motivation, same experience, same tasks. Yet 2 different estimations.

Once the estimation has been done and the sprint completed, what do you think that will happen? Same skills, same tasks so it is very likely that both teams will complete the same amount of work. Yet the first one will complete “18 points” and the second one will complete “30 points”.

Our first thing to keep in mind is that every estimation can only be considered for the team that has provided it. Extrapolating an estimation to different teams makes no sense at all.

*Practical example 2: *

Team A has worked on Project 1 for three months, developing a website that involved a basic signup and login, landing page with dashboard and some informative views and reports.

During 6 sprints the performance of the team has yield a velocity of 22 story points per sprint.

Once the first project is finished, the same team moves on to another one, another part of a website that involves an integration with a third party API and a Stripe payments gateway. None of the members of the team has extensive experience developing third party API integrations.

What do you think will happen? Once the backlog of the second project is estimated by the same team, can the product owner assume that the velocity will be the same?

The answer is no, that assumption can’t be made.

I’m not saying that the speed cannot be the same, but the assumption can’t be made because the nature of the tasks to implement has changed, and that may impact the velocity.

The situation described above can even happen within the same product development, if the scope change is relevant enough.

At the end of the day, we have to make the following assumptions and keep them in mind:

• A team will always estimate the same way (more or less).
• As more sprints are completed, the team will have predictable measure of “how many story points is the development team able to complete in a sprint” – this measure is the velocity of the development team.
• The velocity will be stable as long as the circumstances are stable, that is: Same team, Same project, Similar tasks taking into account the team skills.
• The Product Owner uses the velocity and the amount of story points remaining in the backlog to forecast how many sprints will be necessary to complete the tasks (with a security cushion, of course).
• The velocity of a development team makes only sense for a given team in a given project. It is not a measure that can be extrapolated to another development teams and/or projects.

Finally, let’s revisit how do teams normally provide estimations in story points. As we mentioned, there is not a universal mapping points-time, so for some teams 3 story points is the effort that can take a day and for some other team it can take 2.

However, there is a common practice that many development teams use, which is to provide estimations using the fibonacci sequence instead of a linear sequence:

Why is that? The answer is simple. The bigger the task, the bigger the uncertainty of the estimation. If a developer is estimating a task and thinks that it is something that will take a couple of hours we can expect that the margin of error is small, it will normally end up taking between an hour and a half and 3 hours.

But what happens if the task is estimated to take 5 days? In this case, what can happen is that it may be taking up from 4 to 7 days.

Using a Fibonacci scale helps us gather this uncertainty.

What the team does is to assign story point values to user stories following the fibonacci sequence, using one of the following values: 2,3,5,8,13,20 …

This system can be also seen as a “sizes” system, a user story can be estimated as XS, S, M, L, XL, XXL — same as we do with the clothes.

What is important in here is that we have moved away from having to commit to a time box to finish each user story (estimation in time) and are in a situation where the team only has to tell us how “big” each user story looks like.

Let’s talk about backlogs

As Product Owners we would like the pace of the development team to be as predictable as possible, in order to be able to forecast safely when the major improvements of our product will be ready so that we can coordinate with the business and marketing side of our work.

This predictability is tightly related to the estimations of our development colleagues. The bigger the uncertainty or their estimations, the less predictable they are, the more problems we will encounter when forecasting campaigns or commercial actions along with market ready implementations.

Let’s consider 2 backlogs, each of them with a load of 100 story points, estimated by the same team in the same project. But with a small difference.

During the last 12 sprints, the team has delivering an average of 33 story points per sprint. Giving the load remaining in the backlog, it should take 3 additional sprints to finish the tasks.

In which of the two cases should we as Product Owner sit more comfortably?

Personally, I would be more confident on the delivery date in the first case. It may require a little bit more than 3 sprints, but I don’t think the deviation would be as significant as the risk that the second backlog pose.

In the previous section I stated that the bigger the estimation in story points is, the bigger the uncertainty of that estimation. The uncertainty of an estimation means RISK.

A product manager should always aim to minimize the risk of a product unless the situation calls for the contrary. There is a practical way of minimizing that risk taking into account the initial estimations of the development team:

Basically, what we want to do is to stay alert and always consider splitting the user stories that are estimated by more than X story points.

Why X?

Well, as we’ve discussed, that X highly depends on the team, so there will be developers that estimate that can deliver 16 points per sprint while others will estimate the same amount.