There is a real battle between people who go for estimations with story points, T-shirt sizes, or hours vs. people who ditch those and support the #noestimation approach.
My answer to this cause is you can not have a one-size-fit solution for all situations.
The Cynefin model helped me make up my mind about whether to use estimations for my teams.
First of all, let's examine what the Cynefin Framework is all about:
The Cynefin Framework is a problem-solving tool that helps you put situations into five "domains" defined by cause-and-effect relationships. This enables you to assess your situation more accurately and respond appropriately.
- Obvious Contexts – "The Domain of Best Practice."
A situation that has happened to us before is clear, with no unknown variables like the sprint work structure.
You should assess the situation to create a list of todos, categorize based on procedure, and then establish your response on the adherence to the list.
- Complicated Contexts – "The Domain of Experts."
You know what you need to do; you simply don't know how to achieve it, like balancing the sprint work and unplanned change requests.
You need to assess the situation, analyze what is known (often with the help of experts), and decide on the best response using good practice.
- Complex Contexts – "The Domain of Emergence."
A known situation, still with many unpredictable factors and variables like introducing a new knowledge-sharing initiative in the organization.
Rather than trying to control the situation or insisting on a plan of action, it's often best to probe a solution that has helped in similar situations, then observe, look for patterns, and encourage the following solution to emerge.
- Chaotic Contexts – "The Domain of Rapid Response."
A situation with no relationship between cause and effect, so your primary goal is establishing order and stability. Crisis and emergency scenarios often fall into this domain.
You need to act decisively to address the most pressing issues, sense where there is stability and where there isn't, and then respond to move the situation from chaos to complexity.
Identifying when you're in a "disorder" situation can be extremely difficult. People here tend to rely on known and comfortable decision-making techniques since it's unclear which of the other four domains is dominant.
It's essential to gather more information in this situation so that you can move into a known domain and take appropriate action.
How can this help us define whether we should be using estimations or ditching those?
1. If you find yourself in a simple domain like the projects you realize are alike, and you provide the same service to multiple customers, then you will need estimations, usually in days/hours/minutes, to make sure that your time-to-market response is predictable. Alternatively, you can use cycle time and lead time for defined request types.
- When people request a website design, they want to know precisely when it will be done.
- When people call a customer support service, they want to know how long they will be in the queue before someone picks up the phone.
2. If you find yourself in a complicated domain like creating a software product (no innovation), you might want to use story points or T-shirt sizes to estimate the PBIs.
- Business people need these numbers to evaluate effort vs. value vs. expense.
- Team members need their velocity to plan their roadmap and delivery.
3. If the situation is a complex one like Data, AI, ML teams usually have, you will have to ditch the estimations as they would be useless, time-consuming, irritating, and wrong.
- Use timelines and deliverables instead, and break things down into small tasks with clear expectations.
- All parties should collaborate and understand that innovation can be unpredictable.
4. In a chaotic situation like one with no product vision, no clear strategy, and chaotic work, estimations might be just useless.
- If people don't know what and why they are building, estimations do not help.
- Focus on creating clarity, first of all.
I hope this sheds light on when or not to use estimations.