Estimations are an integral part of software development. They are required for understanding the costs and effort involved in development, to analyze the impact of scope on time and budgets. When we try to arrive at accurate delivery timelines, we tend to attach a lot of importance to estimates. We try to get very specific and accurate with our estimates. However, an accurate estimate sounds like an oxymoron. Product teams surely need a way to understand costs, complexity, risks, resources, people with specific skills, and so on in order to be able to plan the smartest way to deliver the impact-driven product. It's not just about meeting timelines and staying within budgets. Are product teams wasting their effort and time by focusing on the wrong details (such as accurate estimates)? Are we compromising on individuals and interactions by focusing on tools and processes? How do we keep our focus on outcomes and eliminate wasteful processes that focus on outputs?
We will address the following questions in this chapter:
- Why do we need estimates?
- Why can estimates not be accurate?
- What should be the outcome of an estimation discussion?
If I were to ask you how long it would take you to reach Bengaluru from Chennai, India, would you be able to answer accurately? Probably not. Your lack of familiarity with the two places and how far apart they are, combined with the lack of specifics about what mode of transport, weather conditions, and so on, will render it difficult for you to accurately answer. However, we can answer this question better by building up a familiarity with the domain (the two cities and how far apart they are) and the implementation (what type of vehicle, under what weather conditions, and so on).
A smart alternative would be to look up Google Maps and find a roughly indicative answer to my question, without getting familiar with the domain, but with some assumptions on implementation. However, in whichever way we answer that question, we still don't know why the travel is needed or who is travelling? What does reaching the destination signify for this person? What if the traveler cannot make it to the destination? So, we not only need to know the domain and implementation details, we also need to understand the user context, goals, and risks involved.
What if I told you that I need to get to Bengaluru from Chennai by tonight because I have an important business meeting to attend? What if a heart surgeon has to reach Bengaluru from Chennai to see a critical care patient? What if a college student is making plans to attend his favorite rock star's concert in Bengaluru? The answers to these questions are not best fulfilled by an effort estimate. Instead, it is about exploring the best possible ways for each of those people to reach their destination. The user context in terms of their motivations, emotional state, urgency of their needs, and so in, is very important. What is also important is how much they are willing to spend to find a solution to their problem and what other alternatives they are considering.
Estimates can be provided if we know the domain and implementation specifics, but a meaningful implementation plan cannot be arrived at when we don't understand business outcomes, customer goals, risks, and market realities. We need to ask ourselves if we would want to stick to output-level details (estimates) or outcome-level details (an implementation plan). Our success is in how well we execute the travel plan, not in how accurately we predicted the time. Accurate estimates may make us reliable and accountable for productivity, but a well-laid out implementation plan makes us more reliable and accountable for outcomes. The strength of a product team is not in whether we stick to a committed date, but whether we can commit to a business outcome.
Product teams therefore must answer the following questions, which are not answered by the engineering team in isolation, but by the product teams as a group:
- What are the possible ways that we can meet the success criteria?
- What's the smartest way to test our riskiest proposition?
- Should we build or buy?
- Do we have the skills and resources to make this possible?
- What can I not afford to delay and should build today?
- What are we dependent on to ensure our success?
- What is the effort and complexity involved?
- What are our risks and what trade-offs are we making?
All these questions must be answered in the context defined by the following factors:
- Key business outcomes
- Customer value proposition
- Success metrics
- Internal and external constraints