How long would it take to run to the gas station nearest your house to buy bread, and return home? This question has an answer that we all know — likely 5-10 minutes. We know where to find what we’re looking for, and what products are available. We know how the employees there typically work, and at what time there are likely to be more people in line.
This means we should have no problems planning dinner, and that we shouldn’t ever go without any product. However, problems exist. Sometimes the store is out of stock of what we need, sometimes there are a lot of people in line — or maybe on the way we run into an old friend, who wants to stop and chat for a while.
All of the sudden, a task that was supposed to take a few minutes turns into an hour, or more.
What happens if we ask ourselves how long it would take to fix our car, to fix a broken machine, build a bridge? Even more complicated questions, like how long it will take to come out of the recession, or when the next pandemic will happen?
Estimating a software project is likely closer to our day-to-day scenario described above. We all know we need different types of people, with different knowledge, work history, or experience with different technologies. Different complexities appear within our project, and later others can come up from human relationships.
Quite often, we underestimate the tasks we have because in earlier situations we knew how to fix each problem. How many times has it happened that when we tried to implement something working in one environment, it stopped working in another?
In software development, we should check even the things we know are working. Like Murphy’s Law says, “what can go wrong, will.” That’s why we need to do unit tests for different scenarios. This helps us to get an acceptable quality of the new software module we’re working on. This way, we can try to minimize the risk of error and increase our return on investment.
The closer a product is to production and needs to be sent back to a developer because something has broken will be more expensive, and diminish our return in investment. The worst case is that the error happens in production, because that means it will already be impacting the final user. Not only will we have an economic loss, but a loss of reputation as well.
Anyone can estimate a task, but to be able to do it well isn’t easy. Generally, the phenomenon of positivity bias tends to mean that we imagine something will take less time than what it actually will. We tend to not consider alternative scenarios because we aren’t aware of everything that can happen.
That’s why to be able to estimate well, we need to be familiar with each one of the components required, and how they are programmed. We need to know the environments we have implemented, and also the complexities that the client and the business might have. We need to make an effort not to underestimate our tasks and understand that each component could fail.
It’s easy to make mistakes because our brains can visualize only things we have seen before when developing software, but additionally, we should also try to imagine other scenarios that can could happen. We shouldn’t fall in the trap of only that which we know. We need to try not to underestimate tasks and understand that it’s likely each of the components could fail. It can be commonplace, we need to add some sort of patch to what we have already finished in a piece of software that is in production, but we should try to minimize those changes.
This all doesn’t mean we should just increase our estimations but rather it’s a reminder to be attentive to the things we need to know well. This way, we can achieve an estimation that is as precise as possible. Make estimations, and later monitor the remaining time in a task is a good practice that helps to improve estimations. The results of this simple process will surprise you.
As a good practice, we could include the revision of estimations in our weekly sprint retrospective, in which the whole team participates, and learns about the results obtained. An honest assessment, avoiding bias when making new estimations, combined with the experience in each of the revisions will help to improve results. When tasks are familiar, the risk of unplanned work is also lower compared to those newer components or interfaces we haven’t explored yet.
In a planning session, we should keep in mind the skills (abilities and knowledge) of the person working each task, as well as their familiarity with the work environment. As a recommendation, when writing requirements we can note that it is always welcome to add more detail in the story requirements, or to defects reported to avoid misunderstandings. A deeper case analysis can help us verify each work item and help us carry out functional tests on behalf of development before turning in each software component. The objective in planning is that all parties reach agreement without any pressure.
Currently in the realm of techniques available, planning poker allows participants to play a card game that allows them to estimate tasks without knowing the cards of their colleagues, where once the cards are face up on the table, each player must justify their value chosen. In this way, each player is able to have their own opinion, and the goal is to look for consensus based on the Fibonacci sequence, according to the complexity of each task. Here, an important factor is the knowledge each participant has, as they will be required to defend their position, or to sway their colleagues opinion on the amount of work required to finish this type of task, according to their estimation.
The spirit of this type of planning is to create sincere dialogue, unanimous agreement, without having to follow the majority’s opinion. It also is helpful to think of the work as a team, instead of it being done by just one person. The estimation should be thought of without outside influence and made to be as close to reality as possible. The goal isn’t to estimate as quickly as ppossible, but rather to imagine how the task execution will play out in reality, and the obstacles that could appear in on the way, given that when we execute the task we will likely encounter situations we haven’t planned for. Keeping our tasks small and dividing them when necessary will help us estimate and avoid surprises.
Another bias that can appear is when we are working under pressure, and our client or boss needs our work turned in in a shorter period than our estimations would indicate. We might think that we can complete our work just because of an authority bias, where we try to fit a deadline, instead of allowing a process to take the time that it needs to. What usually happens is is that we are required to turn in software before our estimated completion date. My personal recommendation is to always focus on quality even if that that means taking more time.
A cohesively designed and tightly coupled software component will likely last longer and be more robust and flexible to future changes. This is because it will likely require less maintenance, and can evolve along with the rest of the application. If we focus on quality, we might run short on time, but that will be a question of helping the client to understand that the effort we invest will have its benefits. When something works well, the user benefits from it daily, but no one remembers if a product took a little longer to be completed. On the other hand, when something doesn’t work, the user will be negatively impacted by it daily, which can in turn turn wear out our relationship.
The only thing left for us is to take a chance and begin our predictions. The more experience we have estimating tasks, the less time wit will take us in the future. Try to be imaginative and avoid any type of bias. Usually estimating a task never takes less than what we had planned initially planned.