Many of us work in environments where the question "when will you be done with X?" matters. Some of the examples I have seen recently are:

• The business team wants a certain set of functional enhancements as well as performance & scalability improvements. Can we get both done? Will one need to take a back seat to the other?
• A customer has a "deployment window" that we want to hit with a certain set of functionality. Do we look like we will make it? If not, what adjustments might we make?
• A customer wants an early warning if the cost of a project is likely to go over a certain amount.

Today I am reflecting on how difficult it is for individuals and organizations to deal effectively with uncertainty and ambiguity, and how the underlying belief in the possibility of certainty has such a strong hold on us. Examples of that desire for certainty that have appeared on my radar over the last few years include:

How long should a team spend analyzing something before doing something?

A team I work with recently used a "spike" to investigate how to implement a new system capability. The spike was open for two sprints, although I am not sure how much effort was expended over the course of those two sprints. The fact of this spike being open for two sprints made me curious about the trade-offs made… given the agile value of Working Software over Comprehensive Documentation, was the team leaning too far in the direction of comprehensive documentation? And if so, how would they know? 

In thinking about this trade-off, I like the following thought experiment… what would each extreme look like?