While most of the team members care about estimate just as part of a routine of the Scrum methodology, estimating tasks is quite important for those members of the team, or even of the company, that deal with senior management or with priorities. In the 16 years of experience as a software developer, I have often faced some recurring misunderstandings of the idea of estimating that, in my opinion, have a ground in the lack of interest that most of the team members have about this aspect of the work.

An aspect of the work that is essential!!!

When I was part of a brand new team, and we were in the phase called “Storming” (for more info, click this link), the team had different ideas of the importance of estimating. In different companies I have found some rules applied without a real reason, as dogmas, and I want to speak about some of them.

Bugs should not be estimated

This has already happened several times. In one company this was happening based on the principle that “bugs does not bring value to the company, therefore they should not be estimated“. In another one “bugs are difficult to be estimated, they should not be considered“. I just found this article and I think it is quite interesting to share it here.
My personal point of view is similar to the one in that article: if my team has to spend time in fixing a bug, for example 2 or 3 days of one of the most experienced developers, how can we ignore the time that is required? In an environment with no blame culture, a bug is something that simply happens to everyone, but when it is identified it should be estimated to understand the impact on the quantity of work that the team can achieve during a sprint. And also for other reasons that I will discuss later…

Design tickets should not be estimated

That is a similar reasoning that the one for bugs. In some teams that I led we were not estimating the effort we put in the design, but there was a reason: either there was a person dedicated to that (me) or the design had little to no impact to the performance of the team, e.g. if the design meant taking the team, going in a room for an hour and at the end the design was over.
If a task has usually the same order of magnitude, in terms of time spent, than a coffee break… I am not going to estimate it. But if a design ticket can involve 2 or 3 weeks of work for one or two experienced developers, I need to take those days into account.

All tickets should have a fixed value in terms of story points (generally 1)

I guess the principle was “if story points are values that don’t reflect any exact quantity of time, what is the difference among a value and another? Let’s put all 1 and let’s basically count the tickets – let’s use greater values only for tickets that we think we should split“.
Well, my personal experience is that, in the “performing” phase (again, please look at this link), a team usually tends to try to work on tickets that are designed to be of a similar dimension, meaning that teams define a quantity of work that is “perfect” as a size of a ticket and try to model all the tickets so that they are about that dimension. In one of my teams that was about 2 or 3 days of work on average (obviously junior devs were taking a longer time, but this is an example to give an idea).

Anyway, that is not a good reason to use always the same value. The logic of using the Fibonacci sequence is that smaller tickets are easier to estimate, but this does not mean that sometimes you have bigger tickets and situation for which it is ok to accept a bigger quantity of work. Also, giving always the same size makes a bit useless the estimation process, and teams using that principle end up not estimating at all, preventing also a clear discussion related the opinion on challenges that each ticket may trigger.

Only product tickets should be estimated

This happened to me just once: product owners were creating tickets, and dev were estimating those tickets. Even if this may look like the normal situation in a scrum team, there is a huge problem: Product Owners have usually to discuss concepts all together, so for their nature huge projects tends to be grouped in few tickets. On top of that, Product Owner usually have not the ability to split the work based on the technical tasks required.
In those cases, product tickets tend to be Epics more than stories. But if those tickets will be written as stories, technical ticket may become “subtasks” (I am speaking about JIRA’s types of tickets). You may understand that there is absolutely no problem in having the work being one level higher (PO writing epics and devs writing stories/normal tickets) or one lower (PO writing stories and devs writing subtasks). The problem is what is estimated: estimating product owner tickets may be more complicated because product owner tickets may be bigger, therefore they may bring more uncertainties. On top of that, if the team does not estimate the task that they do it is difficult to catch up the quantity of work/ rework/ design/ bug fixing that they do

But what does the estimate want to show?

That is something that I think should be clear: estimates make forecasting easier, and forecasting is not just required by senior management. Forecasting can be used to anticipate work, to create space for experiments, to understand when to raise a concern or a risk before the team is in danger, e.g. if your frontend team is running out of work because the backend is taking more time, if the holidays that have been requested will generate a bad situation that can be mitigate, if moving the tickets may create a bit of time at the end of a sprint for tech investments. This brings enthusiasm in the team, because it avoids issues and it brings interest in personal development or study of new technologies.

On the other side there is an aspect that is usually ignored: estimates brings clarity on what happened during a sprint. For example, if there are lot of uncertainties for a new project, you may want to measure how much work has been spent in fixing requirements that were changing because they were specified wrongly since the beginning. For that reason it is definitely a good idea to estimate bugs even when they are closed, if an estimate was not done at the beginning. In that case, more than estimate it is to evaluate the effort invested, and this helps to establish patterns, that eventually help the team capturing the contingency required to the future estimates, improving their ability to estimate. If in each sprint the team usually spends 10 points fixing bugs that happens during the sprint, at the third sprint in a row that this happens you may think of taking 10 point less to make room for bugs.

Estimating is not a science… but there are techniques

The last argument that most of the people who don’t want to do estimates use is that estimates are nothing about science, so every method has the same value. But this is totally false: there are techniques to make the estimates more efficient and reliable, and even if shit happens anyway, one failed sprint does not mean that the following one cannot be successful enough to recover from the previous failure.

In my past teams we have been, sooner or later, very good at estimating. There are lot of tips to follow, but then it is also true that some adjustment are required based on the team and the company culture.
I found quite funny listening in some companies that “we don’t estimate bugs and designs” but then lot of teams had tricks to cover the gap that these rules were bringing, like removing capacity to architects (estimating a ticket or removing capacity of a team member when that ticket is brought into the sprint is not the same thing?).

My personal suggestions to improve the estimates are banal but not to be ignored:

  • keep tickets small, because small tickets are easier to be estimated
  • if a task, however you call it, is taking time to a team member, create a ticket and estimate that task
  • try to identify patterns: if a team member, usually a senior, is involved in lot of meetings, for example, consider only a percentage of his effort, or create tickets to estimate the effort that he invests on those meetings
  • use at least the range from 1 to 21 in the Fibonacci sequence, and reserve 21 to tickets that, for a single dev, would not fit an entire sprint
  • don’t be lazy in estimating, and be honest

I hope this helped. Stay tuned!!!

Share