Estimating coding tasks has been in the heart of every popular methodology out there. Take for example scrum, at the beginning of every spring, planning, prioritizing, breakdown and estimation are key activities.

 

Estimating tasks using models

For me estimating a task is something easy. I try to think about previous experiences and roughly calculate a number. A simple search on the web around estimation will bring 10s of estimation models that people have used over time – like Putnam, cocomo etc… All these models rely on input from humans and humans are not good at estimating something they do not know. Software development is filled with unknowns, bugs from external libraries, features causing regressions, features that require more features. The unpredictability of software development is a reality that is not going to change anytime soon. The reason agile methodologies are so popular is that estimates are less relevant to them.

Another factor that makes these models problematic is that humans can be influenced. There have been many studies where groups of engineers are given the same description for a set of requirements with a couple of different time hints (e.g. In a description of a website the stakeholder adds a comment like “I am not expert, but I think this development should take less than 2 months” – that single statements affects the estimates of the group).

Other ways engineers can be influenced by are culture, emotional stress and social pressure. People can be even influenced by the scale they are asked to give the estimates in, is it hours, days, weeks, sprints. We should remember that software development is an activity that needs a high degree of creativity, inventiveness and social interaction, so most people are unable to estimate consistently on similar tasks.

 

Iron triangle

The first time I saw this idea of picking 2 out 3 sides of the iron triangle was around 15 years ago when I was in first year at university. The iron triangle model’s constraints of project management and these constraints are considered “iron” because you can’t change one without impacting the others.
Scope is the work to be done – such as features and functionalities.
Resources include budget and the size of the team.
Time is when the teams will deliver a release or a milestone.

Let’s see some healthy ways to treat time and scope. In the left triangle the scope is flexible, so the development teams are empowered to descope if they need to. In the second triangle time is the estimated part that means the team is in full control of the delivery date.

We tend to see the first one in agile and the second in waterfall methodologies.
Resources is an interesting constrain since they take time to ramp up and usually the surface area is not always enough to add more engineers. You all know the classic example of the nine women giving birth in 1 month

 

What happens when all sides are fixed?

A hidden side of the triangle, the Quality, will become the variable part. Feature quality and code quality will drop to balance the 3 fixed sides. Low quality usually creates a chain of events. This will start with a large number of defects and until all of the defects are fixed the releases will be delayed. This in turn will make your customers anxious and dissatisfied. Usually the natural response to quality issues is an increase in UI automation and formation of large QA teams with large QA cycles. But when code quality drops, usually the team’s morale drops which translates to high staff turnover. So now that the goal of the team is a DATE. Everyone gets blinded by it, forgetting about core principles like healthy CI builds, TDD, automated testing and finally linting.

 

Why estimates become fixed?

We talked about the negatives of a fixed side iron triangle but when does it happen? What are the drivers for changing an estimate into a development budget? Well, it mainly comes down to 2 reasons – knowledge and trust.
Your first group that would be trying to fix all sides of the triangle are your customers. They may not necessary understand that for the project to be successful, the software development needs to be flexible on either requirements or the delivery time. But also, a customer may not necessary trust the software vendors as they may have had a bad experience.
Another group could be a board member/director or “The business”. They could be pushing for something to be delivered on a date. This maybe attributed to their background or lack of understanding of the impact of their demands. And the final group is ourselves. We fix estimates because we may not trust our managers or be afraid that we will be blamed and not be seen as professionals.

 

Hints to avoid a fixed triangle 

Breaking down your features into Musts, Shoulds, Coulds is a positive step. Once you know your Musts, repeat that process and find the Musts of the Must tasks, in other words try to define your mvp. Once you have a handful of Musts, try and work on them, forget the Shoulds and Coulds. Don’t split the workload of a team into different features. Try to work on 1 feature per team at a time and take any steps you need to make sure that when a feature is done it does not need revisiting. By releasing often and at fixed intervals one creates an aura of trust around the project. Creating a heartbeat of releases will gain the support and trust the project needs. Try and avoid big release dates – I think this is self-explanatory. I would say avoid RAGs and burndowns, because they are linked to a big date. Let’s not forget that usually your best employees or an expensive project manager will maintain those documents -so even if they spend 4 hours a week that’s 10% of their time. Burndowns apart from showing progress are also making a false promise since the burndown was built on inaccurate data.

 

Summary

What I have described today is not suited for every business and every project. You as a professional will need to approach software development in a way that is productive and successful for your business. What I am trying to highlight here is something that I was warned about 17 years ago…. but it still happens today. Gc