Beyond the success of Kotlin: a documentary about how and why Kotlin succeeded in the world of Android development.

How to Estimate Your Work Tasks Using Story Points: Examples with Cats

The author of this article is EPAM Project Manager Olha Rudenok.

Project Manager Olha Rudenok


Introduction

I have worked as a Project Manager for 4+ years. Over the course of my career, I’ve worked with various projects, methodologies, and frameworks, and communicated with specialists of different roles and levels. One of the biggest struggles in almost all my teams were story points.

Questions that I heard from project to project were: “Why do we need story points if we can just set hours for those tasks?” and “I can accurately estimate in hours, or at least in days, so why do you ask for story points?” etc. I sought an effective way to convince my colleagues that we are on the right path with relative estimation. Finally, I discovered some useful techniques to teach them how to use story points, and I share my findings below.

This article is useful for those who have never worked with story points or those who have had some experience but still struggle with using them. The article includes some theoretical information, but the main purpose is to provide practical exercises that will help you understand the principles of estimation in story points.

What story points are

Let’s start with the description. Story points can be:

  • a metric used in Agile project management and development to estimate the difficulty of implementing a given user story, or
  • an abstract measure of the effort required to implement a user story.

In simple terms, a story point is a number that indicates the difficulty level of the story.

There is a formula that can be used for identifying story points:

Formula for story points

Benefits of using story points

It is important to remember that a story point is a relative unit of measurement. It is not the same as hours or days, which are absolute units.

Time-based estimations don’t consider complexity and risks. Also, each team member’s personal valuation of a task and can vary depending on their seniority, understanding of the task, and previous experience with similar tasks.

Story points are used in Agile frameworks because they:

  • improve the accuracy of estimates,
  • reduce planning time,
  • predict release dates more accurately, and
  • help teams improve performance.

Practical tasks

Below is a practice scenario that can help you better understand story points. You can also use it to help your teams understand the idea of story points.

Exercise 1

Draw a horizontal line and try to place several tasks on it from smaller to bigger considering the effort needed to complete each task, the task’s complexity, and any possible risks during execution.

Horizontal line for placing tasks

Select everyday, rather than technical, tasks for this activity. This is particularly important if you are going to ask your team to do the exercise. You want it to be easier for everyone to understand the tasks and place them in the right order.

For example, tasks could be:

Task examples

The goal is to understand the principle of relative estimation by arranging the cards in relation to each other rather than by the exact number of hours, day, weeks, etc., needed for the execution of each task.

In my case, the result of this exercise is:

Example of placing tasks on a horizontal line

This result reflects my personal perspective. But if you work in a team with other colleagues, you need to discuss each task together and come up with a joint decision about its placement. For example, for my husband, it would be easier to paint the fence than cook dinner. So, for our team (not my individual) response, cooking dinner will be a bit harder while painting the fence will be a bit easier, changing the picture:

Example of placing tasks on a horizontal line depending on the effort

The same principle applies to development tasks: you may have people with different experience on the team, and the purpose is to come up with an average value of the task difficulty.

Exercise 2

Perhaps there are a large number of tasks and no need to have a separate value for each of them. Instead, what you need is a way to group tasks by their level of difficulty.

A T-shirt sizing approach can be used for this purpose. This is when you are given a set of units replicating commonly used clothing sizes: S, M, L, and XL. You and your team should jointly decide where each of the tasks from the previous exercise go. In my case, the result is the following:

T-shirt sizing approach

The point is that the difference between sizes is really visible. You won’t confuse tasks assigned to Large with those assigned to Extra Large as you might, for example, if you had 16 vs. 17 hours estimated for a couple of tasks.

What is the benefit of such an approach? It saves the time for estimation. Sometimes, estimation can take more time than execution. And it is not always possible to provide an exact estimation.

Exercise 3

Finally, we’re closer to story points. In software development, T-shirt sizing is commonly used to preliminarily estimate some big scopes of work (e.g., features), and story points are used to evaluate particular stories (smaller units of a feature).

A very popular rating scale is the Fibonacci sequence. It is modified a bit for the estimation purpose, and often starts with 0.5 or 1:

Fibonacci sequence from 0.5 to 21

Why this sequence? For the same reason T-shirts are used: the difference between values is visible. You will never confuse 13 with 21 as you might do with 20 and 21. Using the sequences provided below is not a good idea:

Two sequences. The first one is 1, 2, 3, 4, 5, 6, 7. The second one is 1, 2, 4, 8, 16, 32, 64

We’ve considered the problem with using option A, but you may ask “What’s wrong with option B?” The answer: we never know if a task is exactly 2 times bigger/smaller than another.

Let’s practice now with story points. For this exercise, I suggest using the same context for the user stories, but with the different set of requirements given.

Here are the examples:

  1. As a cat lover I want to pet a cat every day to be happy. Given: I am not a cat owner.
  2. As a cat lover I want to pet a cat every day to be happy. Given: I am a cat owner.
  3. As a cat lover I want to pet a cat every day to be happy. Given: I am a cat owner. I am currently in Poland. My cat is currently in Ukraine.
  4. As a cat lover I want to pet a cat every day to be happy. Given: I am a cat owner. The cat lives with me at my home.
  5. As a cat lover I want to pet a cat every day to be happy. Given: I am a cat owner. The cat lives with me. It sits on my lap right now.

The first step is to decide which user story is the most clear and easiest to execute for you and your team, and assign it the lowest value, which is 0.5 story points. Which task can be estimated in this way? The one that has the lowest level of uncertainty and that requires the minimum effort: As a cat lover I want to pet a cat every day to be happy. Given: I am a cat owner. The cat lives with me. It sits on my lap right now.

And the most difficult task of the options provided will be to pet a cat considering that I don’t even have it. Thus, I am going to give that story 21 story points.

I hope that with the examples above, the idea is clear, and you now have a better understanding of estimation in story points.

The views expressed in the articles on this site are solely those of the authors and do not necessarily reflect the opinions or views of Anywhere Club or its members.
Related posts
Get the latest updates on the platforms you love