Why Estimations are WRONG?

Managers are frustrated by developer estimations. Why are the estimations always wrong? Why can't the team estimate better? What's the correct estimation approach to use?

📢 My next Live Q&A Session about Unit Tests is on Wed 30th April 17:00. If you’re an Optivem Journal paid member, get your 100% discount ticket.

Upgrade to join the Live Q&A for free:

---

Many developers have to estimate User Stories & Bug Fixes. During the Sprint Planning, they estimate with Story Points (which gets converted to hour-based estimations by Management).

Then, at the end of Sprint, Management sees that most of the items are NOT done. They have to explain to the PO why only a few items were completed.

Then in Retrospectives, the team reflects on what they could have done to estimate better.

Management will try to force developers to estimate better. Management might even setup better reports in JIRA, and buy tools for better time tracking…

… but the problem remains… The vicious cycle continues…

So what’s the solution? What’s the “correct“ way to estimate, so that estimations are more reliable?

What are the Estimation Approaches?

I appreciated Vivek’s description of two dominant estimation approaches (via chat):

Approach 1: Data-based

Approach-1:

Take a look at past data for similar type of tasks and predict the time / scope.

Need to keep 1 axis flexible - either time or scope.

If time kept fixed, come up with list of features to be delivered - both in worst-case and best-case scenario - based on past data.

If scope kept fixed, come up with best-case and worst-case time needed - based on past data.

Approach 2: Team-based

Approach-2:

Let developers come together and decide time needed for each feature/user-story.

Let all participating folks come up with an estimate at the same time (so that estimates form tech-lead/senior-devs don't create bias in others' estimates).

Take some kind of average between the estimates obtained.

If someone's estimate is too low - ask them why they think so - may be he has a better way to solve the problem.

If someone's estimate is too high - ask them why they think so - may be he is anticipating a roadblock/challenge that others haven't thought of.

Which Estimation approach should we choose?

Now we get to the question raised by Vivek (see chat) - which estimation approach should we choose? How do we satisfy management?

Personally, I feel approach-1 is a bit tedious and impractical.

Combined with approach-2, I feel we should have some goal to strive for within a somewhat flexible timeline; and have enough trust in the developers to do their job - practice CD - optimize for quick feedback loops - cut corners(maybe some unneeded portion of a feature) wherever necessary - and do their best to meet the goal.

What's your take on this topic? I am hoping for a more concrete answer that can ideally satisfy the management in orgs, where it's become a common practice to have fake agile practices.

No Continuous Delivery? Forget Estimations.

The problem is that most organizations are “fake“ Agile. This means they may have some organizational practices associated with agility (iterative development - e.g. with Scrum) but they do NOT have technical practices that are prerequisites for Agility.

In the Principles behind the Agile Manifesto, the first principle is (bolding for emphasis):

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Unfortunately, most companies fail right here, on the first principle, because they are NOT practicing Continuous Delivery.

Continuous Delivery is necessary (but not sufficient) to be agile. Therefore, if we are NOT practicing Continuous Delivery, we’re NOT Agile.

If were are NOT practicing Continuous Delivery, then changes are unsafe & expensive.

• Unsafe Delivery: Shipping regression bugs to customers

• Expensive Delivery: Late bug fixes are very expensive

This has one important implication: Unpredictable Delivery. The total time to implement a change is NOT predictable. The reason is, in larger projects, the biggest cost of maintenance is the cost of regression bugs. Without Continuous Delivery, we have to rely on Manual QA to detect regression bugs. This late detection of bugs is expensive and unpredictable solving regression bugs is the main source of unpredictability. When we have that level of unpredictability, it doesn’t matter what estimation approach we use - all estimation approaches are wrong.

Continuous Delivery is as MUST-have.

Continuous Delivery is a MUST-have for predictability. The organization must practice Continuous Delivery, to be able to have predictability & reliability in the development process.

If you’re practicing Continuous Delivery, it doesn’t matter too much which estimation approach you choose. I’m not too fussy there. I’d even recommend a hybrid approach, you may use past data as the baseline, but ultimately the team should do the estimations for the specific User Stories they’re working on. However, I wouldn’t use those Estimations as written in-stone, but rather to get a relative feeling of difference in magnitude, and perhaps a motivator for User Story decomposition.

To summarize:

• (Most organizations) If your organization is NOT practicing Continuous Delivery, then I can guarantee, that your estimations will be unpredictable. It doesn’t matter whether you use Scrum, JIRA, story points, hour estimates; it doesn’t matter whether you use data-driven or team-driven estimates; the ESTIMATIONS will be WRONG - big difference between estimations & reality.

• (High-performance organizations) If your organization IS practicing Continuous Delivery, then your cost of change will be much lower, your predictability will be much higher. There will be higher trust and less micro-management. Then, estimation might not even be a concern anymore, as the team’s improved predictability will speak for itself.

---

📢 My next Live Q&A Session about Unit Tests is on Wed 30th April 17:00.