Nowadays, it would be tough to find people who claim that the agile methodology is ineffective. Virtually all software development teams attempt to be agile. A common way of starting with the agile methodology is adding a couple of its components to a team’s workflow. One of the most popular components, considered somewhat essential, is the story points estimation. However, how many teams have stopped to consider this component’s real impact? In particular, whether estimating the time spent on every single task actually brings value. In my experience, it does not.
To be agile, we must know the advantages and risks of the tools we use. So, let’s look at the pros and cons of story point estimation. In this article, we will examine whether proper iteration planning and being agile without time estimates of every single task is possible.
Agile sprint estimation: A little background on how I started working with Agile
In every project I was involved in, I heard people praise the agile methodology. So it’s no surprise that we always worked with some kind of Scrum approach: we had Sprints, Daily Standups, and Plannings with estimations. In one company, we even had an Agile Coach. As a result of the Plannings, we tried to cram loosely coupled tickets into, usually two-weeks long, Sprints. This was all according to numbers called estimations, which in reality, were just guesses. We had been told that as time passes, we should be able to determine our velocity, and from that point, our estimations will be magically correct. However, nobody knew the purpose of these estimations. I never heard phrases like delivering value or adjusting to changes which are original Agile concepts.
We didn’t have a clue what the added value of working (or pretending to work) with this Agile component was, but we did this because the alternative was Waterfall. And nobody wanted to work with the Waterfall methodology. After some time, I started thinking about why we need to stick to the processes which do not make us work better.
Agile sprint estimation: Does story point estimation bring value?
In my experience, teams working in Scrum are putting significant pressure on estimating how many tickets a team would be able to fit into Sprint.
Usually, it goes like this:
- Team Leader: How much time will it take you to implement X?
- Developer: I guess it will be three days.
- Team Leader: Ok, so what do you think you will be able to finish in the remaining two days?
Sometimes the task was Story Point, and sometimes there was the famous Planning Poker. But in any case, the goal was to reach an agreement on how many tasks a person could commit to for a Sprint.
From my observation, task estimation does not bring any value and, instead, causes a lot of harm to productivity and satisfaction. It can even decrease the quality of the end product.
Two of the most often anticipated benefits of ticket estimations are:
- the ability to predict when features or fixes will be delivered to the customers
- the ability to calculate a team’s velocity, which enables us to better estimate the team’s capacity in the future.
Sprint estimation: Do story point estimations impact users?
It’s important to note that developers usually cannot implement a complete, non-trivial feature in one step. A feature requires multiple tasks, which are sometimes divided into several components. The results of each particular task are not visible before the entire feature is completed. In that case, users won’t be able to notice a difference. They simply do not care whether you created an interface as a step in the direction of implementing a new way of calculating some value for a specific set of customers. What’s more, if they would notice any change at that moment, you’ve ended up with a bug.
Users will not know that a change that was supposed to be delivered on Tuesday got postponed to Friday. Usually, the resolution of days does not bring any significant difference. If you miss an important deadline by a few months, then it might be a problem. But in my career, I haven’t experienced any problems with delays, even in the magnitude of weeks.
Why does a team’s velocity constantly change
It seems to me that finding a team’s velocity is the highest level of mastery in Scrum that many managers dream of achieving. However, my belief is that our focus should not be on being proficient in some methodology but on effectively providing value to customers.
I understand why some managers are drawn to planning every day in a sprint. At first, story points and velocity may seem like good models for expressing a team’s actual performance. However, my experience tells me otherwise. Unfortunately, in the long run, story point estimations cannot help a manager figure out how many tickets a team can deliver in a specific period. You have different people, different initiatives, different sizes of tasks and different life events for each teammate. A manager cannot expect a team to maintain its velocity over an extended period. People experience many situations in their lives that affect their productivity and ability to estimate consistently.
Frequently, there are life events like vacation, burnout of one of the team members, childbirth, divorce, promotion and many others which are unpredictable and strongly influence a team’s performance. That means an abstract, fixed number will not be meaningful and constant in a larger time period when people and teams change.
Does story point estimation hurt productivity?
Until now, we have gone over why I consider Story Point estimation to bring no value to a team’s productivity. Now, I would like to go even further and say that it’s not only useless but harmful. From my observations, the main reason software development teams are obligated to commit to a set of tasks in a two-week period is the possibility of management creating incentives to motivate us to get more out of ourselves.
It sounds sensible according to one of the theories of productivity called Parkinson's Law. This is the idea that you spend the exact amount of time you have to complete a task. Therefore, people seem to think that assigning as many tickets as a specific person claims to be able to complete is a great way to ensure that person’s time will be fully utilized and, as a result, provide an adequate return on investment.
I’m not sure whether this fact is connected to the busy times we live in, or it comes from the fact that because we’ve been paid tons of money, people who pay us want us to be fully utilized, like the computation resources inside our servers.
Mathematicians even have a separate field for that called Queuing Theory. Even in the infrastructure where we optimize for optimal resources, usage when utilization of the servers rises above around 85%, the time required to accept new operations to be executed increases exponentially. In short, no matter the context, overall performance degrades when everybody is too busy.
Usually, the main goal of the planning was to have the team’s capacity cram as many tasks as possible to make everyone busy enough during iteration. But the high utilization is at odds with the creative work and makes the team unable to react to the changes that are bound to happen.
The negative aspects of sprint estimation
It’s obvious that planning is a form of commitment. And there is nothing wrong with giving this commitment, as long as it’s achievable and brings enough value that could make this worthy effort. I noticed that people usually have a strong need for fulfilling their commitments, especially when they work in teams full of ambitious individuals, as software engineers often do. That can result in a situation when people are unwilling to take on an urgent task that wasn’t planned for the Sprint, help others with their work or even cut corners in their tasks. And that’s usually after they figure out that this problem they committed to solving is much more complicated than they thought.
I don’t even need to look for examples of such situations in the distant past, as I was exactly in that position a few weeks ago. I was working on some quite aggressive refactoring and realized two days before the end of the Sprint that I could not finish it on time. With all my knowledge, self-reflection, and experience, it was really hard for me to resist the temptation to skip some work I’d planned to do regarding minimizing the impact of the potential failure during that process. Fortunately, I did not skip it. And you know what? We were notified about a problem right after the release, but thanks to my countermeasures, mitigation of the issue only took 15 minutes.
It’s never an easy decision. Many developers choose to finish a given ticket at all costs within a given time frame — out of a desire to fit in something as trivial as estimates. In one way or another, it’s not worth it. Especially since sprint estimations are usually unnecessary and self-imposed deadlines that we face no consequences for missing.
Don’t let your users down
I’ve never heard that a team completed all the tickets they committed to during a Sprint. Usually, tickets are moved from one Sprint to the next without a discussion about whether they are still valid and worth continuation. We’d promised to deliver them, so we decided to keep our promise. Due to that, we are doing the same Sprint after Sprint, accumulating this delay over time. People are so accustomed to this process that they don’t see any problem.
One of the anticipated benefits of estimating is being able to notify customers in advance when a feature will be delivered. Despite that, we see that our estimations are wrong. Moving tickets from one Sprint to another is now a new normal, and there is nothing a team tries to do to fix that. So we must now do anything to finish tasks not only because of committing to them but also because making promises leaves your customer in anticipation of something. When they don’t get it, they will feel disappointed. And we all know it’s better to be surprised than let down.
I don’t recall a situation where a software company notified me in advance that they planned to put in place a new feature in a product I use within a specific time. Usually, a new feature just appears, or we are asked to enable it on our own if we want to.
Scrum is not the only way to be Agile
I feel that right now, more and more people negatively view Scrum. This downturn, in my opinion, comes from the fact that Scrum brings no value, and I find that Sprint Planning based on strict estimation is the most harmful part of its processes.
The problem is that, with time, people started to consider Scrum the only Agile methodology. That brings a negative attitude to Agile despite true Agile principles being valuable and worth following in modern organizations. We should focus on good prioritization and finding ways to work on projects in parallel, not Story Point estimation, which wastes time and has no value for your team’s efficiency. I encourage all teams working with Scrum to consider changing their approach. But for now, I’ll leave you with a post from the creator of Scrum.
