When working in software projects, it’s usually a good idea to estimate the overall effort, as it helps coordinate and plan initiatives across a company.
Although there are different ways of estimating software tasks, in this article I will discuss Story Points, and what to do and not to do when using them.
Story Points
In Agile, Story Points are a unit of measurement used to estimate tasks based on their relative effort and uncertainty, not time.
For example, let’s imagine a series of boxes of different sizes that need to be filled with a product.
We can choose a box as a reference, and decide that the effort to fill it is three Story Points. This value is not three days, or weeks, or ideal dev days. This is just an arbitrary number. T he key is that everyone in our team knows this point of reference.
If we are shown a larger box, we know that the effort to fill it is greater than three Story Points. How many exactly is up to us to decide (this is again an arbitrary value). Similarly, if we get a smaller box, the value will be whatever we agree as long as it’s less than three.
As we start filling boxes, we may notice that the effort of filling a box twice the volume of our reference is not twice the effort, but less. Next time, we’ll use this insight when we estimate other similar tasks.
Our team may be challenged by receiving cylindrical boxes to fill, rather than rectangular. Or we may be asked to fill the boxes with different products. We can use our previous knowledge to try to estimate the effort, and we’ll surely get it wrong the first times, but we’ll learn as we go, and the more we do it, the better our estimates will be.
Of course, estimates need to be consistent for all this to work. The key to making a good estimation that are consistent is to identify similar tasks worked on by our team, and the Story Points that the team set on them.
Team Estimates
Task estimation is a team effort, but sadly some people fail to see this and decide to estimate tasks on behalf of their team.
Usually, a team will have a pool of tasks to work on. Anyone with a non-zero chance of working on those tasks should be involved in the estimation process, because:
- We need to be able to understand a task to give a meaningful effort estimate, doing team estimations fosters teams where everyone understands the work that needs to be done. That means that anyone can take any task, or work with a teammate with minimum context transfer.
- Sometimes it may not be easy to get agreement on the effort for a task, but every disagreement is a new opportunity for the team to work on and improve on team collaboration and psychological safety.
- If done by just one person, estimations can sometimes include biases like seniority and skills. However, when done by a whole team, they can be balanced by different perspectives, usually leading to more accurate estimates.
Since tasks are estimated on a specific team’s experience, they can’t be applied to other teams. Technically, when new people join a team, it becomes a new team, and most likely, estimates won’t be the same.
Some teams try to teach their estimates to new-joiners, but I don’t think that this is necessarily the best approach. Instead, we should embrace change and just start the estimation process all over again: define a point of reference, and estimate tasks based on it. Because the point of reference is arbitrary, we could use a task estimated by the original team to define it. And from then on, let the new formed team come up with their own relative estimates.
Estimates Are Not Commitments
The main use of Story Points is to predict future productivity based on past productivity (this is called Velocity Tracking).
If last week we filled boxes equivalent to ten Story Points, it would be reasonable to expect that this week we can complete ten Story Points, irrespective of the number or size of boxes we fill.
As I explained in this other article, many times there will be discrepancies between the expected value and the real number of Story Points completed because estimates are only useful best guesses.
In my experience, a big problem that many teams have is that people in leadership roles want to improve productivity, and they base their analysis on whether a team completed all the tasks that they thought they would.
I am all up for improving productivity, and if you have not noticed already, all my articles are oriented toward how we can be more effective software developers. However, focusing on the wrong data often leads to misleading conclusions and poor decisions. Trying to improve a team’s performance by looking at the estimates will usually lead to undesirable results.
For instance, once I worked at a company that wanted to improve their overall productivity. To do this, they treated estimates as commitments. Although sometimes there was some flexibility, I witnessed employees being pressured to complete projects in impossible timelines. Many engineers had to regularly work long unpaid extra hours to avoid being poorly evaluated due to unmet delivery times. In the end, the company achieved their goal of being more productive by making people work more hours rather than by improving any processes. And they also managed to have a great number of talented but unhappy employees who decided to leave the company,
This is one example of why I believe that, instead of focusing on estimates, we need to look at what problems our teams encounter, what is not letting us be more productive, and seek solutions to those problems. I have observed many times how, by focusing on improving the ways of working and having leadership that understands that estimates are not commitments, we can achieve effective and engaged.
Happy coding!
José Miguel
Share if you find this content useful.
Follow me on LinkedIn to be notified of new articles.