#NoEstimates: The Product Owner Flying Blind?
Why it’s Worth Taking a Closer Look at the #NoEstimates Approach
Estimating effort is a standard practice in many projects and also in product development. Depending on the project, management, the customer, and other stakeholders want to know:
- When will the product be ready (e.g., to schedule product launch or marketing efforts)?
- Are we on track (e.g., if delivery dates have been promised and there are penalties for non-compliance)?
- What is the impact if we expand the scope?
- Do we have enough resources?
- How much budget do we need?
The Product Owner is the stakeholder’s point of contact in this process, and they expect that he/she answers these questions.
In many cases, effort estimations take place for these very reasons.
Developers and estimates
The Development Team is usually not very enthusiastic about estimates. From experience, they know: Software development is complex, and effort estimations are often time-intensive and wrong. The more ambiguous the requirements and technologies and the more people involved, the more complexity.
The above questions are far away for developers. They are more interested in the following points:
- Do we all understand the same thing by the User Story?
- How complex is the development?
- What are the risks?
- Do we have the necessary knowledge in the team to work on the feature?
- Is the technology known?
- Will we manage to finish the story in the next sprint, or is it too big?
For this reason, in agile development, we usually do not estimate in terms of effort but in Story Points or other abstract quantities (e.g., T-Shirt Sizes or Animals). The Story Points represent a number that helps developers to answer their questions.
Agile teams use methods as Planning Poker or Magic Estimation for estimation. The goal of discussing the size is to share and have a common understanding.
