Practical Estimates

It all started while working as CTO (first-time though) at and attending the conference Codemotion Rome 2019, I was listening to Daiany Palacios talking about hers “The trap of averages. How to avoid it in software development estimates” in particular about doing estimates using the Montecarlo method. That moment something triggered in me, like an epiphany… I had put a lot of effort into my process improvements, but that was another spark to keep raising the bar again.
Then during a job interview, some time later, I’ve got asked about my method, and they were interested in my approach.
This episode, a few days later, got me thinking that maybe I could share it to the world 😉
Since it kinda worked for me most of the times (let’s say 80% of the times), I could have formalised it and tried to fix the weak spots. So here it is.
This method is only valid at some stage of company maturity, early ones could benefit from it, mature one could avoid it entirely. It depends on the company’s needs.

How did I come up with Practical Estimates? It was mainly to let the concept be transparent with the name and to make the adoption easier. Difficult names will make harder for the management to buy the concept, here are some failed attempts:
  • Skipped Estimates: no-one wants really to skip them
  • Quick & Dirty Estimates: management wants precision
  • Fair Estimates: too crowded on Google because of “fare estimate”
  • Guesstimates: terms like “guess” or “opinion” won’t work because very subjective
  • Practical Projection: changing the term estimate would confuse the management in the lexicon
  • Sensible Estimates: it could work, but still not buyable enough
  • Practical Estimates: boom! They want estimates and gonna get it, plus they are practical which is a bonus because the process is fairly quick.




What management really means is that estimates are promises — even forced estimates — and the team needs to keep their “promises,” even if they never promised.
Ron Jeffries

Estimate Of Timeline - Dilbert by Scott Adams
Estimate Of Timeline – Dilbert by Scott Adams

With 90% of work done, the remaining 10% is refining the requirement, misread details, small UI-UX tweaks, blockers, code-review comments, build failure, etc. This 10% is highly underestimated and consumes significant time.
Ranganathan Balashanmugam

Dilbert by Scott Adams
Dilbert by Scott Adams

Individuals often consider the best possible outcome.
Dr Simon Moss

Different Time Estimates - Dilbert by Scott Adams
Different Time Estimates – Dilbert by Scott Adams

Company Maturity Assessment

This concept is based on Frederic Laloux’s definition in his book “Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness
Colour Description Guiding Metaphor Key Breakthroughs Current Examples
RED Constant exercise of power by the chief to keep foot soldiers in line.

Highly reactive, short-term focus. Thrives in chaotic environments.

Wolf pack
  • Division of labour
  • Command authority
  • Organised crime
  • Street gangs
  • Tribal militias
AMBER Highly formal roles within a hierarchical pyramid.

Top-down command and control. Future is the repetition of the past.

  • Formal roles (stable and scalable hierarchies)
  • Stable, replicable processes (long-term perspectives)
  • Catholic Church
  • Military
  • Most government organisations (public school systems, police departments)
ORANGE Goal is to beat the competition, achieve profit and growth.

Management by objectives (command and control over what, freedom over how)

  • Innovation
  • Accountability
  • Meritocracy
  • Multinational companies
  • Investment banks
  • Charter schools
GREEN Focus on culture and empowerment to boost employee motivation.

Stakeholders replace shareholders as the primary purpose.

  • Empowerment
  • Equalitarian management
  • Stakeholder model
  • Businesses that are known for idealistic practices (Ben & Jerry’s, Southwest Airlines, Starbucks, Zappos)
TEAL Self-management replaces the hierarchical pyramid.

Organisations are seen as living entities oriented towards realising their potential.

Living organism
  • Self-management
  • Wholeness
  • Evolutionary purpose
  • A few pioneering organisations (Patagonia, Buurtzorg, FAVI, Morning Star, ESBZ)
Source: Frederic Laloux, Reinventing Organizations [Nelson Parker, 2014]
Check your organisation with the following assessment:
ℹ️ Info: This estimation method is mostly applicable in red/amber/orange organisations.


  • Not everyone is lucky enough to have the top management buy smoothly the uncertainty and the software lifecycle without many deadlines or de-scoping functionalities. See No Estimates.
  • I’ve tried this method with a fairly small team of 7 people.

The 4 Key Processes

Sorting Process

  • Use the Eisenhower Matrix to group items together
  • Focus only on Urgent-Important, Urgent-Not Important, Not Urgent-Important (in this order)
    • Urgent-Important: We know we cannot do everything right now, so they’re gonna be planned
    • Urgent-Not Important: It’s just urgent postponable stuff, but unfortunately is “urgent”
    • Not Urgent-Important: Real schedulable work
    • What about Not Urgent-Not Important: Let them stack up in the backlog, some day you’ll prune…
  • Within a sector order by priority
    • Use any relevant metric: urgency, complexity, date, profitability, and so on

Estimation Process

  1. Get a prioritised tasklist following this order:
    1. Urgent-Important
    2. Urgent-Not Important
    3. Not Urgent-Important
  2. Do Affinity Grouping based on the type of the activity: issues, task, enhancement, feature
  3. Do your estimation of a task based on the historical data of how long in average it took based on the activity type
    1. Each activity type has different timings, the time to fix an issue it is different from building a new feature. So treat them differently to achieve a better precision
  4. Review with the team if the estimates sound roughly good enough
ℹ️ Info: Do have a look at No Estimates since the concept is great, you’ll find more interesting topics that will help you.
ℹ️ Info: We are bad at estimating and each one takes into account his perspective. To be objective we need to be backed by data, even if it’s not precise.
ℹ️ Info: Try to gather as much data as possible about the historical lead time or worked time from project tracking tools by querying directly their internal database. For example, if you use self-hosted GitLab or Jira you can access their PostgreSQL database and harvest data.
⚠️ Pay Attention: There should be no link between abstract units (Fibonacci series, t-shirt sizes, and so on) and time. Remember that the management cares about time, it’s how human measure things. They will find a way to hack any framework to map it to working days.
⚠️ Pay Attention: Each team must have its own estimation (they cannot be mixed up) and they should be added together to obtain the final figure.

Planning Process

  1. Use a Gantt Chart to help you visualise the workload
  2. Plan the work across different resources
    1. Plan at 70% capacity (think about sick days, holidays, meetings, …)
  3. Cut out whatever is not in the defined time span
  4. Review with the team the Gantt Chart

You could use a schedule like the following one:

  • Monday – Thursday: work on urgent issues and scheduled work
  • Friday: work on support issues and repaying technical debt.

Execution Process

  1. Each week check the progress
  2. Swap task assigned to resources whenever someone finishes all his/her workload
  3. Deliver each week part of the work, use a Feature Flag approach to make sure you can control the impact of the functionality.
ℹ️ Remember: Agile is about fixed time and cost and flexible scope. For more details check the Quality Triangle.

Pro & Cons

  • Quick estimates
  • Saving the time of the team
  • Enough precision
  • Not enough precision
  • Requires constant checkpoints


Rather than measuring using the classic velocity metric, it is way better to do the math based on the Running Tested Features. RTF has 3 main benefits:

  • It is Running, hence it has been released in production, creating value for the end-users.
  • It is Tested, meaning that it has been validated in different stages: unit testing, functional testing, integration testing and acceptance testing.
  • It is a Feature, meaning that has real value for the end-users.

If you find you’re going to miss the planned deadline try to give as much notice as possible, in this way you can act accordingly and try to limit the damage. Also, make sure this kind of events are rare and you don’t miss too many deadlines, otherwise it’ll take a toll on the team’s morale.


Use burn-up charts for better visibility of changes of scope (which happens all the time).

burn up chart

A burnup chart clearly shows both completed work and project scope. The project will be completed when the lines meet.

The advantage of a burn up chart over a burn down chart is the inclusion of the scope line. It clearly tracks when work has been added to or removed from the project.