This article is part of the series Planning Software Development.
When we develop software, people often will ask us questions like:
- When will it be done?
- How long will it take?
- How much will it cost?
- What will be done by 2019-02-25?
- Can [feature set] be done by 2019-02-25?
- What can I get for 200 000€?
- What team size do we need to finish before 2019-02-25?
Those are related but slightly different questions. And a good answer to them would be useful to some people, often even to the people on the development team - the people who should give the answer - themselves.
And we often do not want to answer those questions. And we have reasons.
Our Answers will not be “Good”
Or at least not good enough for our own standards.
There are some inherent difficulties in estimating software development: Things about our work, things happening in our teams, that make estimating hard. And by hard I mean that our estimates will be “inaccurate”.
That is not a problem per se: All estimates (and also all forecasts, which are a type of estimate) are inaccurate. The value is still useable and useful, because it is based on the best information we have available right now.
But we do not want uncertainty. We are humans, after all. So, we do not want to produce data where we know that it is “wrong” from the start.
Our Answers May not be Useful
Sometimes, we do not want to give an estimate because we know we cannot produce it to a degree of certainty that would be useful.
We may be reluctant to answer “How long will [feature X] take?”, because there are too many factors that influence this number.
We might be tempted to answer “How much work will [feature X] be?”, because under some conditions, this question is easier to answer. But we have to know beforehand what exactly “Feature X” means. So if we answer this question far ahead of starting to work on “Feature X”, this may impede our agility, if we are not careful.
We can often produce the most meaningful answers to “How many work items can be done within the next month”, because this is a capacity-based forecast. In a stable team that already has enough historical data to run some simulations, this number will be the most accurate of the three.
But we will be most reluctant to give an answer when we think that the person asking does not need it at all.
Our Answers are often Ignored
Somebody asks “us” - the development team - a question. We answer with an estimate. When we suspect that our answer does not and cannot change the outcome of some meaningful decsisions, we feel like we have wasted our time.
“Can [Release] be done before September 22nd?” - “No, probably not.” - “But sales promised that to one important customer. Try it anyway.”
“Please estimate those 20 user stories, so we can sequence and cut scope” - “OK, here are the estimates…” - And then nothing happens…
“Based on our estimates and acutals, we are way behind schedule. We should cut scope now so we do not face crunch time in two months.” - “No, cutting scope is not an option.”
I bet every developer, tester and other development team member knows situations like those. And after hearing something like that, they probably have been thinking: “Why am I even talking to you when you ignore me anyway?”…
Our Answers Might be Used Against Us
Whenever we give an estimate (or a forecast, which really is just a special kind of estimate), we risk that somebody thinks this is a promise. At least in dysfunctional organizations.
And it does not matter how much disclaimers we add.
“In the best case scenario…”, “Our simulation said the most likely release data is…”, “Measured in perfect engineering days…”, “…but you know that a story point is really a range.”
The micro-manager will not hear those. They will come back later, screaming “But you promised…” or “Why is our velocity down this sprint?”. If this is happening in your organization, you have some major cultural problems. You are seeing Agile Anti-Patterns. And in such a dysfunctional environment, we do not want to give any answers that might be used against us.
No Answers - The Solution?
For what it’s worth, do not answer questions when you do not need the answer. But…
I am talking about not wanting to give answers today. If we could give them, they might be useful. Even if they are not usefull all the time, they may be useful in some phases of software development. At least to some people, and at least in some situations.
Even though our answers may not be “perfect” or even good enough for us, there are situations / times where we are able to give better answers than in other situations.
And when the answers are ignored or used against you, you are seeing some severe dysfunction in your organization. In such a situation, you probably should not answer those questions - But you probably are also not allowed to deny an anser. So, now might be a good idea to look for “Agile Anti-Patterns” and to start addressing them - You have bigger problems than just giving “good estimates”.
