Agile Estimation. Or #NoEstimation. Who knows?

I already wrote about Agile earlier, but it is a rather important topic for me (I was involved with Agile Alliance very early on). And one of my favorite discussions on the topic is the value of estimation. Whether you are aiming to estimate for the hour, or doing only TShirt estimation, you do know, that estimation is an important part of agile processes because it helps teams plan and manage their work effectively. Estimations are used to determine the amount of time and effort required to complete a task or project, which helps teams prioritize their work and make informed decisions about how to allocate resources. Additionally, estimations help teams set realistic expectations and deadlines for themselves and their stakeholders. In agile methodologies like Scrum and Kanban, estimations are done using techniques such as story points, which are relative measures of complexity rather than absolute measures of time or effort. This allows teams to adapt to changes and uncertainty more easily.

On the other hand, there is a tribe of #NoEstimation practitioners, who say that the value of “no estimation” is that it can eliminate the need for time-consuming and potentially inaccurate estimation efforts, allowing teams to focus on delivering working software and satisfying customer needs. It also promotes a culture of continuous improvement, where teams focus on delivering small, incremental changes and learning from them, rather than trying to predict the future. In “no estimation” approach, the team focuses on delivering smaller chunks of work, called “Minimum viable products” (MVP) which provides the maximum value with minimum effort. This approach is based on the assumption that the customer or stakeholders don’t know exactly what they want, and the team should deliver small increments to gather feedback and iterate on the product. This way, the team can deliver the product with more accuracy and customer satisfaction. This approach is more suitable for companies that have a high degree of uncertainty and volatility in their environment and for projects that have a high degree of innovation.

A quick overview of the pros and cons for this:

ProsCons
Estimation
  • Helps teams plan and manage their work effectively
  • Allows teams to prioritize their work and make informed decisions about resource allocation
  • Helps teams set realistic expectations and deadlines for themselves and their stakeholders
  • Useful for making decisions about project scope and feasibility
  • Can be time-consuming and potentially inaccurate
  • Can lead to unrealistic expectations and deadlines
  • Can be difficult to adapt to changes and uncertainty
  • Can lead to over-engineering or gold-plating
No Estimation
  • Eliminates the need for time-consuming and potentially inaccurate estimation efforts
  • Promotes a culture of continuous improvement and learning
  • Suitable for projects with a high degree of innovation and uncertainty
  • Focuses on delivering smaller chunks of work, called “Minimum viable products” (MVP)
  • May not be suitable for projects with well-defined requirements and constraints
  • May require a significant change in mindset and approach for some teams
  • May result in a lack of long-term planning or goals
  • May lead to delays if the customer or stakeholders need specific features or functionalities

So, where can the ideas of Estimation vs #NoEstimation applied to?

  • Estimation in a software development project: A software development team is tasked with building a new application for a client. The team uses agile methodologies such as Scrum, and they estimate the amount of time and effort required to complete each user story using story points. This allows them to prioritize their work, set realistic deadlines, and manage their resources effectively. However, this process can be time-consuming and may not always be accurate, especially if the requirements change or new information comes to light.
  • No Estimation in a product development project: A product development team is working on a new IoT device. They are using “no estimation” approach. They are focused on delivering small, incremental changes and gathering feedback from customers and stakeholders. They deliver Minimum Viable Product (MVP) that provides the maximum value with minimum effort. They are not trying to predict the future and are continuously improving their product based on customer feedback. This approach allows them to adapt to changes and uncertainty more easily, but it may not be suitable if the project has well-defined requirements and constraints.
  • Estimation in a construction project: A construction company is building a new skyscraper. They use estimation to determine the amount of time and resources required to complete the project. They use Gantt chart and critical path method to plan and manage their work. However, this approach can be difficult to adapt to changes in weather, materials, or other factors, and it may lead to unrealistic expectations and deadlines.
  • No estimation in a research project: A research team is working on a new medical treatment. They use “no estimation” approach and focused on conducting small experiments and gathering data. They are not trying to predict the outcome, instead they are continuously learning and improving their research based on the data they gather. This approach allows them to adapt to new information and uncertainty more easily, but it may not be suitable if the project has specific deliverables and deadlines.

So, no, I haven’t given a straight answer on Estimations, as there isn’t one. Agile is what you make of it, it is NOT one size fits all 🙂