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:

  • 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 🙂

Agile vNext (in 2023+)

In 2023, we still speak about how to introduce Agile? That seems to be pretty slow with today’s standards, everyone is already doing agile 😀 So, what the future of Agile looks like?

Future of Agile in a diagram

The future of Agile development methodologies is likely to involve increased focus on collaboration and communication among team members, as well as continued evolution of Agile practices to better support remote and distributed teams. Additionally, it is possible that we will see a greater emphasis on integrating Agile principles with other methodologies, such as Design Thinking, to create more holistic and effective approaches to software development. Additionally, with more and more companies adopting Agile methodologies, Agile is becoming a part of mainstream. Next to Agile itself, Design Thinking is the big other technology getting to mainstream.

Agile and Design Thinking are both iterative, user-centered approaches that prioritize flexibility and collaboration. Agile focuses on the rapid development and delivery of working software through the use of cross-functional teams and incremental, iterative development cycles. Design Thinking, on the other hand, is a problem-solving approach that emphasizes empathy for the user, rapid prototyping, and iterative testing to arrive at innovative solutions.

While Agile and Design Thinking have different origins and are used in different contexts, they share many common principles and can be used together to create a more holistic approach to software development. For example, a Design Thinking-inspired approach can be used to generate ideas for new features or functionality, which can then be rapidly developed and tested using an Agile methodology.

Combining Agile and Design Thinking can also be beneficial for creating a more seamless and efficient workflow, as well as ensuring that the end product is not only functional but also user-friendly and satisfying. However, Agile and Design Thinking both have their own set of potential drawbacks.

One potential drawback of Agile is that it can be difficult to plan and budget for longer-term projects, as the focus is on delivering working software in short, incremental cycles. This can also make it challenging to accurately predict when a project will be completed, as requirements and priorities may change during the course of development. Additionally, Agile methodologies can be challenging to implement in organizations that are not used to working in a highly collaborative and adaptive way.

Design Thinking can also have its own set of drawbacks. One of the most significant challenges is that it can be time-consuming and resource-intensive, as it requires a lot of user research, prototyping, and testing. Additionally, Design Thinking can be difficult to integrate with more traditional, linear development processes, such as Waterfall, which can create challenges for organizations that are trying to adopt Design Thinking practices.

Furthermore, Design Thinking-inspired approaches can also be criticized for being too focused on the user and neglecting other important stakeholders or factors such as budget, timeline, and feasibility of the solution.

Overall, Agile and Design Thinking are powerful approaches that can help organizations to develop innovative solutions and create better products, however, careful consideration of the potential drawbacks and a good understanding of the context of the project is required to make sure they are implemented effectively.

Speaking about Agile, we cannot walk past the question, how to choose a framework among Scrum, Kanban, etc. Choosing an Agile framework can be a complex process, as there are many different options available, each with its own set of benefits and drawbacks. Here are a few key factors to consider when choosing an Agile framework:

Kanban VS Scrum
  • Team size and composition: Different Agile frameworks are better suited to different team sizes and compositions. For example, Scrum is often used by small, co-located teams, while Kanban is better suited to larger, more distributed teams.
  • Project complexity: Some Agile frameworks, such as Scrum, are better suited to handling complex projects with multiple dependencies and rapidly changing requirements. Others, such as Kanban, are better suited to more straightforward projects with well-defined requirements.
  • Organizational culture: The Agile framework you choose should be compatible with the culture and values of your organization. For example, if your organization values predictability and stability, Scrum may not be the best choice.
  • Prior experience: If your team has prior experience with a particular Agile framework, it may be a good idea to stick with it, as it can take time to fully understand and implement a new framework.
  • Goals and priorities: Different Agile frameworks have different strengths and weaknesses, so it’s essential to choose a framework that aligns with your project goals and priorities. For example, if you’re looking to improve team collaboration, Scrum might be a better choice than Kanban.

It’s important to remember that Agile is not a one-size-fits-all solution, and there’s no perfect Agile framework. The best framework for you will depend on your specific situation and context. It’s also important to note that Agile frameworks are meant to be flexible and adaptable to the needs of the team and project, so even if you choose one framework, it’s important to keep an open mind to adjust and adapt as needed. And same goes for choosing Agile and/or Design Thinking – it might be not the best fit for your team.