The dark side of story points

I recently hung out with developers from my previous job and the conversation turned to how we estimate tasks. We all work in different companies already, so it was interesting to get various points of view.

All of my friends said that yes, they do estimate tasks - in story points using Fibonacci numbers, in hours, or in t-shirt sizes (S, M, L, XL). But I was surprised to hear what they did after they got an estimation.

One of my friends told me, how religiously their product manager calculates story points and happily reports to the CEO that this sprint they made more points than the previous one. I won't be surprised if the CEO praises them for the increase and even sets the goals accordingly.

The product manager praises developers and they strive to make even more points in the next sprint. Sounds great - developers are motivated to write the code quickly, tasks are rapidly closed, the business moves forward. Right?

- Not quite.

If you praise developers for points, they will (even unconsciously) overestimate tasks and choose tasks by the maximum number of points in the minimum time. Moreover, PMs themselves will think about points, and not about value for users and the company. The desire to get more points leads to shipping feature after feature and does not allow teams to stop, take a step back and think about what they are doing and why.

Skeptics would argue - it's a PM's job to decide what a team should do and why. Developers should implement what the PM told them to implement, quickly and without errors. And points help to do it.

Many teams work like this, but it is ineffective (I will explain the accent on this word later). First, a team is better at finding a solution than one person. And secondly, a successful product manager is not the one who generates brilliant ideas and forces the team to implement them. A successful product manager knows that the more people involved in the process, the better the result. That's why they report problems to the team, focus on them, involve everyone as much as possible in the process of finding great solutions, help bring them to life and unlock the potential of the entire team.

If the dialog within the product team is built around how quickly and profitably for the company to solve the problem of users, each developer, designer, and analyst begins to think about it, using their professional background and unique experience. Everyone generates ideas, and as a result of cooperation, even better ideas come to life. People feel motivated and the team releases the right features faster.

But if the whole team is concentrated on counting story points, their focus shifts, and the team implements what the product manager came up with with their head (which is not always the best, no matter how much we would like it) and often forgets about the value for users and businesses.

As promised I'm coming back to the word ineffective, that I used earlier.

Be efficient means doing something in the shortest time with minimum effort and being effective means geting to the desired outcome. For instance, for a worker being efficient means to tight as many nuts as possible. And being effective means to solve the problem, for example assembling a machine.

Surprise! We live in the 21 century! We don't work at the conveyor and don't tighten the nuts. We don't need to be efficient and optimize the number of similar operations per hour. We solve complex intellectual problems that nobody had solved before us. The result of our job is not the number of nuts tightened or code lines written, but the impact our decisions make on the user experience and business. Whether we have achieved our goal or not, whether we have been effective or not.

Why not? Please, estimate, if it helps you to plan sprints and distribute tasks between developers. The main thing is to remember that you grow what you measure. And if the company's goal is paying customers, then success needs to be measured in paying customers but not in story points, features shipped, or code lines written.

Any activity takes time and energy. There are 24 hours in a day, and only 3-4 of them are productive. It is better to spend this time on something useful. The team and product manager are either counting the story points or looking for ways to get more customers and provide them value.

If we decid to estimate tasks, let's do it efficiently, with the least amount of wasted time. By default, teams estimate tasks on the common sprint planning. However, I have never seen this work well. Perhaps this approach is suitable for very small highly specialized teams, where each member is closely involved in all tasks. But if we work on several parallel projects, every one of which is done by the part of the team (as it usually happens), then estimations on the common planning are a waste of time in my opinion.

In order to estimate a task you need to talk it through in detail. To talk through all tasks for the sprint for 10 people you need several hours. Not everyone present participates in the discussion of each task, the rest sit and yawn. Time is wasted, you still can't go into details, the estimates are far from reality.

At Nautal, we went through the usual planning with Scrum Poker and realized it wasn't right for us. As a result, we agreed to small grooming or working sessions with developers who were going to participate in feature development + PM + tech lead. We discussed the feature in detail, dwelled on the difficult moments, and roughly estimated it. After that, the task went to final polishing and prioritization.

We do not have a strict system of evaluation that has been honed over the years. We have tried different approaches. Lately, we are estimating in days/hours, considering that 1 day = 5 hours. Small tasks or bugs can be assessed in 1/2 or even 1/5 of a day.

We estimate tasks in small groups - during the same work sessions where we discuss the projects' scope. A common sprint planning takes very little time (max 30 min) we use it only to synch and bring an already estimated list of tasks to it.

The purpose of the estimation is to make sure the developers have enough projects to complete and decide whether we can include a certain task in the sprint or not. If we see that a task is time-consuming, but its impact is not large enough compared to other initiatives, we cancel or postpone it.

After the planning we basically forget about estimations, we don't measure velocity and don't care about story points. Instead, we try to focus on the quarter OKRs and strategic goals.

As an Amazon Associate I earn from qualifying purchases.