4 min read
During our end-of-year annual sales kick-off conference this week, I witnessed a leader presenting our roadmap to the sales and marketing teams. One of the highlights was announcing the expected delivery date for a new core product in 2024. This announcement was the first I had heard of this expectation, and now expectations have been communicated to the organization. I quickly jotted down a note, “How comfortable are we in announcing this delivery date?“. I thought about my past experiences and the ongoing discussions about the challenges our delivery teams face with deadlines and estimates, even in the Agile era, and it inspired me to create this short post about providing estimates.
In my role and experience, I mentor teams and technical leads. One common issue they face is their reluctance and need for more confidence in providing estimates. The problem I am addressing is the teams’ hesitation or lack of confidence in estimating and sharing a practice that has worked well for me.
For the past 24 years, I have been responsible for providing estimates. I have given estimates for past and current delivery practices. I also aim to support team leads who may feel uncomfortable giving forecasts due to the level of accountability and uncertainties involved. It’s important to note that these questions are typically asked when teams have the least information about the problem they are trying to solve.
Love-hate relationship with estimations
Exploring software estimation dynamics, I have a love-hate relationship with it. Estimation’s psychological impact on teams is complex. While necessary, estimates often face misinterpretation and misuse by management. Communicating probability confidence is a solution. It eases team pressures and brings realism to management. Building buffers and resilience is valuable. Incorporating contingencies is practical, not guilty. Teams intend well, but estimates become stringent targets, fueling fear of commitments. Incremental delivery and feedback increase confidence. Iterative processes refine accuracy and empower teams to adjust timelines based on real-world feedback. Converting unknowns to knowns enhances estimation accuracy, team confidence, and management of expectations. Flexibility and adaptability are crucial in software estimation.
Estimates, regardless of delivery practices
Despite our delivery practices, providing estimates remains crucial. Leaders rely on estimates to set strategy and make informed economic decisions, especially when faced with resource constraints. They are making calculated bets on the future.
For the organization to plan and make decisions, delivery teams must provide estimates regardless of their delivery practices (waterfall, agile, or others). Leaders rely on the target date and hold teams responsible for meeting the estimated deadline.
Many teams hesitate to give estimates because they feel pressured to be precise. They also feel the burden of uncertainty and are accountable to the organization when estimates are shared widely, the sales team counts on the feature, and customers expect to utilize it.
I recommend always giving a probability when providing an estimate. We are X percent confident about meeting the target date based on available information and uncertainties. Considering what we know and potential unknowns, we have a 40% confidence level for our current forecast or estimate.
I recommend using probabilistic estimates as a practice that has been effective when providing estimates. Can we provide a date within a probabilistic range?
Team: At this point, we are x% confident in our estimate.
Product: What level (or percentage) of risk are we willing to assume when communicating delivery deadlines or dates based on the probability of the estimate?
Probabilistic estimations are not just about predicting dates but about understanding the degree of confidence in these predictions. Here’s why this is crucial:
- Reduced Pressure for Pinpoint Accuracy: Traditional estimation methods can put undue pressure on teams to provide precise estimates right from the beginning, even when all variables are unknown. On the other hand, using probabilistic estimations allows for a range of outcomes based on the available information at different points in time. This approach acknowledges the complexity and uncertainty in software projects, relieving the team from the unrealistic expectation of pinpoint accuracy.
- Shift from Certainty to Probability: Shifting the focus from absolute dates and numbers to probabilities and ranges can reduce the stress of committing to specific deadlines or budgets. Teams can express their confidence in terms that better reflect the reality of software development, where uncertainty is always present.
- Increased Sense of Control and Ownership: When teams can provide accurate estimates that align with their understanding and confidence, they feel more in control and accountable for their work. This sense of ownership often increases job satisfaction and motivation as teams perceive their expertise and knowledge to be valued and effectively utilized.
- Encouragement of Open and Honest Communication: Probabilistic estimations create an environment that encourages expressing uncertainty, fostering honest and productive discussions about project timelines, scopes, and risks. This approach helps prevent a culture of over-commitment and under-delivery.
- Reduction in Stress and Burnout: By setting realistic expectations, probabilistic estimations can help reduce stress and burnout caused by aggressive and often unattainable deadlines. This approach supports a balanced workload and helps maintain a healthier work-life balance for the team.
Incorporating probabilistic estimations into product delivery practices improves the accuracy and reliability of project planning. It also promotes the mental well-being of teams by creating a realistic, transparent, and pressure-free environment.
I invite your perspective to analyze this post further – whether by invalidating specific points or affirming others. What are your thoughts?.
Let’s talk: phil.clark@rethinkyourunderstanding.