Practical Estimates - Fabio Cicerchia

It all started while working as CTO (first-time though) at Skuola.net 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.

Concepts

No crazy formulas
Rolling Wave Planning
Effort estimation
Complexity estimation
Time estimation

Why?!

Because…

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

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.	Army	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)	Machine	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.	Family	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: https://www.beyondteal.com/teal-organizational-readiness-assessment

ℹ️ Info: This estimation method is mostly applicable in red/amber/orange organisations.

Notes

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

Get a prioritised tasklist following this order:
1. Urgent-Important
2. Urgent-Not Important
3. Not Urgent-Important
Do Affinity Grouping based on the type of the activity: issues, task, enhancement, feature
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
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

Use a Gantt Chart to help you visualise the workload
Plan the work across different resources
1. Plan at 70% capacity (think about sick days, holidays, meetings, …)
Cut out whatever is not in the defined time span
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

Each week check the progress
Swap task assigned to resources whenever someone finishes all his/her workload
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

Pro:

Quick estimates
Saving the time of the team
Enough precision

Cons:

Not enough precision
Requires constant checkpoints

Measuring

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.

Tools

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

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.